rstoolbox is open source and, thus, contributions are more than welcomed.
If you feel there is a feature that might improve the library here are the steps you need do:
Add a new issue commenting on the feature. Try to explain exactly what you expect the library to do. Examples and example data always help. Features that are most welcomed are:
If nobody offers and you feel confident enough to do it, take the initiative and fork the repo into your own github user.
Ideally, you’ll want to work on a virtual environment; once you have one set up, you can clone your repo into your machine:
git clone https://github.com/YOUR-USERNAME/RosettaSilentToolbox
Start coding, committing and pushing your code. Make sure to add the appropriate Tests and Documentation to your new code.
Whenever you thing your code is working, create a pull request over the original repo. This will trigger the continuous integration test to run and assess your contribution.
When the tests are positive and a reviewer has accepted your pull request, merge the data to the master branch. We do thank you for your time and your improvements to the code.
Tests reside in rstoolbox/tests and depend on pytest.
Development libraries required for tests and documentation building can be found in rstoolbox/ci/requirements_devel.txt.
When running the test, the regular libraries will not be loaded from the default REQUIMENTS file, but from the extra
rstoolbox/ci/requirements_test.txt. The difference between both files being that, while REQUIMENTS requests the
minimum working version for a given library, rstoolbox/ci/requirements_test.txt requires the specified version of the test.
This is important for the test to succeed, specially for graphical libraries such as seaborn,
that might change their visuals from one version to another.
Note
This double library requirements entails the need to take rstoolbox/ci/requirements_test.txt into account when adding a new feature
that needs the last version of an already required library to work.
The easiest way to execute them is through tox; for which three different environments are set up:
tox -e py27
tox -e py35
tox -e py36
As tox works with virtual environments, this might produce some unexpected behaviours in MacOS due to the behaviour of matplotlib.
See the known issues of the getting started section to see how to fix that.
New data to read can be added to the rstoolbox/tests/data folder, but try to be sparse with it and add it only when necessary.
Be aware that the continuous integration will pass its tests if there is not a minimum of the new added code covered by new tests.
Documentation resides in sphinx-docs and depends on sphinx. A full list of requirements for the
tests can be found in rstoolbox/ci/requirements_devel.txt.
Any new function has to be properly documented in terms of function, inputs and outputs. Ideally, example code can be added to help comprehend the effects of the function. Use other functions as guidelines on how to generate documentation.
Be aware that functions are not automatically listed in their appropriate place in the docs, they need to be manually added to the API or corresponding object file.
Once the documentation is done, get into sphinx-docs and run:
make clean
make html
to obtain your docs. You can check them locally opening a server with:
python -m SimpleHTTPServer
Lastly, list your new improvements into: sphinx-docs/releases/Vxxx.txt where xxx represents the higher version listed.