Package: aind-metadata-upgrader
aind-metadata-upgraderUsageTo use this template, click the greenUse this templatebutton andCreate new repository.After github initially creates the new repository, please wait an extra minute for the initialization scripts to finish organizing the repo.To enable the automatic semantic version increments: in the repository go toSettingsandCollaborators and teams. Click the greenAdd peoplebutton. Addsvc-aindscicompas an admin. Modify the file in.github/workflows/tag_and_publish.ymland remove the if statement in line 10. The semantic version will now be incremented every time a code is committed into the main branch.To publish to PyPI, enable semantic versioning and uncomment the publish block in.github/workflows/tag_and_publish.yml. The code will now be published to PyPI every time the code is committed into the main branch.The.github/workflows/test_and_lint.ymlfile will run automated tests and style checks every time a Pull Request is opened. If the checks are undesired, thetest_and_lint.ymlcan be deleted. The strictness of the code coverage level, etc., can be modified by altering the configurations in thepyproject.tomlfile and the.flake8file.InstallationTo use the software, in the root directory, runpipinstall-e.To develop the code, runpipinstall-e.[dev]ContributingLinters and testingThere are several libraries used to run linters, check documentation, and run tests.Please test your changes using thecoveragelibrary, which will run the tests and log a coverage report:coveragerun-munittestdiscover&&coveragereportUseinterrogateto check that modules, methods, etc. have been documented thoroughly:interrogate.Useflake8to check that code is up to standards (no unused imports, etc.):flake8.Useblackto automatically format the code into PEP standards:black.Useisortto automatically sort import statements:isort.Pull requestsFor internal members, please create a branch. For external members, please fork the repository and open a pull request from the fork. We'll primarily useAngularstyle for commit messages. Roughly, they should follow the pattern:<type>(<scope>): <short summary>where scope (optional) describes the packages affected by the code changes and type (mandatory) is one of:build: Changes that affect build tools or external dependencies (example scopes: pyproject.toml, setup.py)ci: Changes to our CI configuration files and scripts (examples: .github/workflows/ci.yml)docs: Documentation only changesfeat: A new featurefix: A bugfixperf: A code change that improves performancerefactor: A code change that neither fixes a bug nor adds a featuretest: Adding missing tests or correcting existing testsSemantic ReleaseThe table below, fromsemantic release, shows which commit message gets you which release type whensemantic-releaseruns (using the default configuration):Commit messageRelease typefix(pencil): stop graphite breaking when too much pressure appliedPatchFix Release, Default releasefeat(pencil): add 'graphiteWidth' optionMinorFeature Releaseperf(pencil): remove graphiteWidth optionBREAKING CHANGE: The graphiteWidth option has been removed.The default graphite width of 10mm is always used for performance reasons.MajorBreaking Release(Note that theBREAKING CHANGE:token must be in the footer of the commit)DocumentationTo generate the rst files source files for documentation, runsphinx-apidoc-odoc_template/source/srcThen to create the documentation HTML files, runsphinx-build-bhtmldoc_template/source/doc_template/build/htmlMore info on sphinx installation can be foundhere.