051cbcbbb1
* re-enable gaff * run espaloma and gaff tests * gaff has two fs michael * Use 8.1.2rc1 * Update linters * Remove Espaloma tests * Apply suggestions from code review Co-authored-by: Iván Pulido <2949729+ijpulidos@users.noreply.github.com> * working on parmchk output * fix pytest warnings * Migrate from pkg_resources to importlib_resources * Remove shipping gaff/ffxml and read everything from parmchk2 * make sure we use older openmm version for testing * [pre-commit.ci] auto fixes from pre-commit.com hooks for more information, see https://pre-commit.ci * test on ci now * [pre-commit.ci] auto fixes from pre-commit.com hooks for more information, see https://pre-commit.ci * decided to keep shipping the xmls * cleaned things up, gave a better name to the set we track gaff atom types * Update openmmforcefields/generators/template_generators.py * updated change log * Added note about how we might remove openmmforcefields/ffxml/amber/gaff/ffxml in a future release --------- Co-authored-by: Matthew W. Thompson <mattwthompson@protonmail.com> Co-authored-by: Iván Pulido <2949729+ijpulidos@users.noreply.github.com> Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
Development, testing, and deployment tools
This directory contains a collection of tools for running Continuous Integration (CI) tests, conda installation, and other development tools not directly related to the coding process.
Manifest
Conda Environment:
This directory contains the files to setup the Conda environment for testing purposes
conda-envs: directory containing the YAML file(s) which fully describe Conda Environments, their dependencies, and those dependency provenance'stest_env.yaml: Simple test environment file with base dependencies. Channels are not specified here and therefore respect global Conda configuration
How to contribute changes
- Clone the repository if you have write access to the main repo, fork the repository if you are a collaborator.
- Make a new branch with
git checkout -b {your branch name} - Make changes and test your code
- Ensure that the test environment dependencies (
conda-envs) line up with the build and deploy dependencies (conda-recipe/meta.yaml) - Push the branch to the repo (either the main or your fork) with
git push -u origin {your branch name}- Note that
originis the default name assigned to the remote, yours may be different
- Note that
- Make a PR on GitHub with your changes
- We'll review the changes and get your code into the repo after lively discussion!
Checklist for updates
- Make sure there is an/are issue(s) opened for your specific update
- Create the PR, referencing the issue
- Debug the PR as needed until tests pass
- Tag the final, debugged version
git tag -a X.Y.Z [latest pushed commit] && git push --follow-tags
- Get the PR merged in
Versioneer Auto-version
Versioneer will automatically infer what version
is installed by looking at the git tags and how many commits ahead this version is. The format follows
PEP 440 and has the regular expression of:
\d+.\d+.\d+(?\+\d+-[a-z0-9]+)
If the version of this commit is the same as a git tag, the installed version is the same as the tag,
e.g. openmmforcefields-0.1.2, otherwise it will be appended with +X where X is the number of commits
ahead from the last tag, and then -YYYYYY where the Y's are replaced with the git commit hash.