epispotfrom the source as it is easier to run tests and debug your code locally.
gitalready, you can install it here: https://git-scm.com. Epispot uses
gitas its de-facto version control system, so it'll help to get familiar with the fundamentals of
git. After you have, make sure to learn the basics of GitHub so that you understand how to submit your pull request when it's time. The first step will be to fork the GitHub repository by clicking the "Fork" button and creating a copy under your username. Next, clone your local copy with
gitby providing the GitHub URL to your fork like this:
epispotcodebase. Run the following commands from inside the folder to initialize the repository properly and get it up-to-date:
pythoninto your shell and you should see an interactive shell similar to the one shown below pop up.
3.6and that the
(epispot)virtual environment indicator shows up. Next, you're ready to build
epispotfrom the source.
pip, just navigate to the root repository directory and type:
firefor the CLI. Finally, you can build
epispotfrom the source
epispot. However, if you would like to reinstall
epispotevery time a change is made and keep a stable
epispotinstallation on your computer, you can run:
epispotis divided into five directories plus the root directory. First, let's go over the root directory (where all the dotfiles are located).
coverage.py, epispot's code coverage analyzer tool, which directories to search and which to ignore.
.codecov.ymltells CodeCov, epispot's external code coverage reporting tool, when to fail depending on the percentage by which code coverage has decreased. The next two are for code analysis.
.deepsource.tomltells DeepSource, epispot's code quality analyzer, where the source files are.
.travis.ymlconfigures a Travis CI routine to run on push to any branch. Lastly, we make it to the
.gitignore. This is a pretty standard Python
.gitignorewhich will ignore the usual cache directories.
README-nightly.mdwhere the latter is used for the
nightlypackage. The same suffix is used in
setup.py, too, where it indicates a different package version.
pyproject.toml, and various others.
.githubdirectory which contains a collection of GitHub-related tools and files designed to optimize the repository. These contain automated workflow scripts that run (e.g. to create documentation), issue and pull request templates, and a
CODEOWNERSfile which is used to determine the owner of each part of the
epispotcodebase. This will be discussed later.
epispot/directories are where the source code is stored.
bin/is used for the CLI and
epispot/for the package itself. Lastly, we have the
tests/directory which contains epispot's testing suite and the
explorables/directory which contains a multitude of explorable examples.
epispot's internal structure is quite simple. Each unit of code has its own file and each subunit its own class. The main files are
__init__.py. The last, of course, initializes the package. The source code runs a relatively simple routine:
models.pyfile. This will show you how to use the docstrings to understand what is going on inside the package. Epispot's code is well-documented and is optimized for additions, deletions, and modifications because it is self-explanatory. For example, if we open up the
Models.get_derivmethod, we can see its source code is simple and well-explained: