Contributing to ESPEI¶
Installing in develop mode¶
It is suggested to use ESPEI in development mode if you will be contributing features to the source code. As usual, you should install ESPEI into a virtual environment.
All of the dependencies can be installed either by conda or pip.
Then clone the source and install ESPEI in development mode with pip:
git clone https://github.com/PhasesResearchLab/espei.git pip install --editable espei
Even if you use Anaconda, it is recommended that you use either
python setup.py develop to install ESPEI in development mode.
This is because the
conda-build tool, which would typically be used for this, is not well maintained at the time of writing.
Develop mode on Windows¶
Because of compiler issues, ESPEI’s dependencies are challenging to install on Windows.
As mentioned above, ideally the
conda-build tool could be used, but it is not able to be used.
Therefore the recommended way to install ESPEI is to
- Install ESPEI into a virtual environment from Anaconda, pulling all of the packages with it
- Remove ESPEI without removing the other packages
- Install ESPEI in develop mode with pip or setuptools from the source repository
The steps to do this on the command line are as follows
conda create -n espei_dev espei activate espei_dev conda remove --force espei git clone https://github.com/PhasesResearchLab/espei.git pip install --editable espei
Even though much of ESPEI is devoted to being a multi-core, stochastic user tool, we strive to test all logic and functionality. We are continuously maintaining tests and writing tests for previously untested code.
As a general rule, any time you write a new function or modify an existing function you should write or maintain a test for that function.
ESPEI uses pytest as a test runner.
Some tips for testing:
- Ideally you would practicing test driven development by writing tests of your intended results before you write the function.
- If possible, keep the tests small and fast. If you do have a long running tests (longer than ~15 second run time) mark the test with the
- See the NumPy/SciPy testing guidelines for more tips
For most naming and style, follow PEP8. One exception to PEP8 is regarding the line length, which we suggest a 120 character maximum, but may be longer within reason.
ESPEI uses the NumPy documentation style. All functions and classes should be documented with at least a description, parameters, and return values, if applicable.
Examples in the documentation is especially encouraged for utilities that are likely to be run by users.
espei.plot.multiplot() for an example.
If you add any new external (non-ESPEI) imports in any code, they must be added to the
MOCK_MODULES list in
Documentation on ESPEI is split into user tutorials, reference and developer documentation.
- Tutorials are resources for users new to ESPEI or new to certain features of ESPEI to be guided through typical actions.
- Reference pages should be concise articles that explain how to complete specific goals for users who know what they want to accomplish.
- Developer documentation should describe what should be considered when contributing source code back to ESPEI.
Since ESPEI is intended to be run by users, we must provide useful feedback on how their runs are progressing. ESPEI uses the logging module to allow control over verbosity of the output.
There are 5 different logging levels provided by Python. They should be used as follows:
- Critical or Error (
- Never use these. These log levels would only be used when there is an unrecoverable error that requires the run to be stopped.
In that case, it is better to
raisean appropriate error instead.
- Warning (
- Warnings are best used when we are able to recover from something bad that has happened. The warning should inform the user about potentially incorrect results or let them know about something they have the potential to fix. Again, anything unrecoverable should not be logged and should instead be raised with a good error message.
- Info (
- Info logging should report on the progress of the program. Usually info should give feedback on milestones of a run or on actions that were taken as a result of a user setting. An example of a milestone is starting and finishing parameter generation. An example of an action taken as a result of a user setting is the logging of the number of chains in an mcmc run.
- Debug (
- Debugging is the lowest level of logging we provide in ESPEI. Debug messages should consist of possibly useful information that is beyond the user’s direct control. Examples are the values of initial parameters, progress of checking datasets and building phase models, and the acceptance ratios of MCMC steps.