Support publishing to PyPI

[ebrahimebrahim]

This adds support for publishing to PyPI by transitioning from the legacy setup.py to pyproject.toml.

The changes are adapted from the output of cookiecutter scientific-python/cookie based off scientific-python/cookie@8c0a1627. See https://learn.scientific-python.org/development/

Changes include:

• GitHub workflows for continuous integration (ci.yml) and continuous development (cd.yml). Each time a GitHub Release is created, it triggers the build, test, and publishing of wheels.
  • (The pytest CI is placeholder infrastructure in case there is a desire to add unit tests in the future)
• Infrastructure for building sphinx-based documentation.
• Extraction of package version from source control by leveraging setuptools-scm. Note that generated source distribution will include the relevant version metadata.
• Pre-commit hooks for checking style.
  • To start with, linting exceptions have been added to pyproject.toml to ignore the style constraints that are not initially satisfied and that could not be safely auto-fixed. Subsequent commits can remove the exceptions and make style changes if there is a desire to do that in the future.
• Dependabot configuration

The major benefit of this proposed update is that HD_BET can be more easily maintained and automatically published to PyPI upon release. This helps bring HD_BET further into the larger python neuroimaging ecosystem by allowing other packages to mark it as a dependency.

The only required step on your side will be to create a pending publisher on PyPI so that the GitHub workflow can automatically publish the package upon release creation. Would be happy to provide more details on any of this.

[ebrahimebrahim]

@FabianIsensee What do you think of this approach to publishing the project and automating some of the routine maintenance? Happy to provide some help in keeping this wonderful project alive!

[FabianIsensee]

Hey, thanks for the PR. This project is no longer actively developed and I welcome ways of reducing the amount of work we have to invest into keeping it running for everyone. Can you please enlighten me how I can integrate the automatic pypi publishing once it is merged?

[ebrahimebrahim]

Once it is merged the steps to publish would be:

• (Once) Create a pending publisher on PyPI (essentially linking this repo to a project on your PyPI account)
• (Every time you want to publish a new version) Release a version of the software using github

(The "automatic" aspect of it is that the publish step is triggered automatically whenever you create a release on github. This is achieved by the configuration in the cd.yml file that is added in this PR)

[FabianIsensee]

Thanks, will do. Might need some more days because I need to fix some things on our end

[ebrahimebrahim]

@FabianIsensee Let me know if there are any more questions I can answer or anything I can help with to move this along

[ebrahimebrahim]

Looks like this was merged and then reverted in 2f99c84979433d9a908f90527ab70885f069082e?

[FabianIsensee]

Yes this is too much at once for me. I do not have the time right now to go through everything I would be merging and understanding it, so I prefer to keep things simple for now. I know this might be difficult to understand from the perspective of an experienced software dev but I have to pick my battles and reduce workload in others. The way hd-bet is right now is what causes the least amount of work to maintain it I am currently considering retraining HD-BET within nnU-Net to keep my software stack consistent. The code in this repo is very old (2018)

[ebrahimebrahim]

No worries at all -- it's understandable. The idea here is to reduce the workload of maintenance and increase accessibility of your tools, but there is of course an up front cost of understanding the tools that automate certain aspects of maintenance. Another person might have accepted not understanding all the tools but you want to make sure you understanding everything in your codebase -- I am the same way :)