Migrate packaging to PEP517/8

[oesteban]

What would you like to see added in this software?

For reference: nipreps/sdcflows#410

Do you have any interest in helping implement the feature?

Yes

Additional information / screenshots

No response

[oesteban]

Better help: templateflow/python-client#117.

The following files in that PR have only stylistic changes and therefore would not apply here:

templateflow/api.py
templateflow/tests/test_api.py
templateflow/tests/test_version.py

The following changes respond to a specificity of the python-client project, so do not apply here either:

.circleci/config.yml [lines 16-20]
.gitignore
.maint/update_changes.sh
.maint/update_requirements.py
MANIFEST.in

PLEASE NOTE that .circleci/config.yml has changes also in lines 176-177. These two last lines DO APPLY in this issue.

Therefore, to accomplish this, we would need to:

1. Remove setup.py
2. Transfer the metadata from setup.cfg into pyproject.toml following the example of templateflow/python-client#117.
3. Remove setup.cfg
4. Update package building and version checking in CI/CD:
   • Update CircleCI: .circleci/config.yml
   • Update GHA: .github/workflows/*.yml
5. Update sections of pyproject.toml as necessary (e.g. build-system and tool.setuptools_scm).

[esavary]

In nipreps/sdcflows#410, hatch is used, and the usage of setuptools_scm is removed, while templateflow/python-client#117 still relies on it. Is there a preferred approach between the two? (For now, I've applied a similar method as in nipreps/sdcflows#410 in #128 )
Edit: I just discovered that templateflow/python-client#120 is also transitioning to hatch. So I think this answer my question.

[oesteban]

All of it is correct -- I posted the above post to clarify that adapting to PEP517/18 and using hatch/hatchling are two different issues.

I don't have a preference and it can be done all at once as in sdcflows (a bit more messy) or in a two-step approach as the templateflow client.

As you prefer (cc @effigies, in case he has a different view).

[effigies]

In the past, I have done the two-step just for the sake of getting it right and reviewed by others with limited time. If something stops working, it can be hard to figure out which part is causing problems.

That said, at this point I've done it enough times I would probably do it in a single shot. So also no strong preference.

[esavary]

Thanks for the input. Got it, I'll stick with the all-at-once approach. However, if it becomes challenging to review, I'm open to breaking it into two steps.