MNT: Switch to hatch build backend and update package metadata #2914
Conversation
|
Version scheme working, but dirty builds again:
|
|
Ah, need to merge |
|
@mgxd One thing I'll note is that flit-scm installs the entire We might want to consider going to setuptools or trying out hatch as the build backend. We can still use |
effigies
force-pushed
the
clean-house
branch
4 times, most recently
from
cc5638d
to
2ab3ebf
Compare
effigies
changed the title
effigies
force-pushed
the
clean-house
branch
4 times, most recently
from
8ff6f99
to
f6d268c
Compare
effigies
dismissed
mgxd’s stale review
Changed quite a lot since last you reviewed
Makefile
Outdated
| @@ -14,4 +14,4 @@ docker-build: | |||
| docker build --rm -t $(tag) \ | |||
| --build-arg BUILD_DATE=`date -u +"%Y-%m-%dT%H:%M:%SZ"` \ | |||
| --build-arg VCS_REF=`git rev-parse --short HEAD` \ | |||
| --build-arg VERSION=`python get_version.py` . | |||
| --build-arg VERSION=`python -m setuptools_scm` . | |||
There was a problem hiding this comment.
should this be
| --build-arg VERSION=`python -m setuptools_scm` . | |
| --build-arg VERSION=`hatch version` |
| # | ||
|
|
||
| [tool.hatch.build.targets.wheel] | ||
| packages = ["src/fmriprep_docker"] |
There was a problem hiding this comment.
just curious - why move to src/
There was a problem hiding this comment.
src/ layouts are increasingly the recommended thing, so I wanted to make sure I knew how to do it. Figured since I was moving the file anyway, I might as well get the experience here.
wrapper/setup.cfg
Outdated
| [options.entry_points] | ||
| console_scripts = | ||
| fmriprep-docker=fmriprep_docker:main | ||
|
|
||
| [bdist_wheel] |
There was a problem hiding this comment.
any pyproject.toml equivalent? [tools.setuptools.bdist_wheel]
There was a problem hiding this comment.
wheel is its own tool. Its docs don't advertise pyproject.toml support, so I didn't try it.
We can drop MANIFEST.in and custom package data declarations by letting setuptools_scm package everything version-controlled in the sdist.
Hatch has a hatch-vcs plugin that wraps around setuptools_scm while remaining flexible. In contrast, setuptools_scm hijacks setuptools' file finding, making package data management cumbersome. And flit handles dynamic version metadata by importing, turning install-time dependencies into build-time dependencies.
Errors introduced in #2914, caught by @mgxd doing the same over in nipreps/nibabies#265.
Changes proposed in this pull request
This PR aims to move away from setuptools+versioneer, which we've been using for a while.
Our packaging needs are actually quite simple so theflit_scmwrapper aroundflitandsetuptools_scmworks with only a little tweaking.One advantage to this approach is that
_version.pycan be updated by runningpython -m setuptools_scm, which will ensure that patching withfmriprep-docker --patch fmriprep=...will get a sensible version instead of the useless0+unknownwhich breaks the reuse of workflow directories.One slight complication is that flit does not resolve symlinks when building sdists. I have added theNOTICEfile to the sdist inclusion list, but I also switched the direction of the symlink so that the authoritative copy is always inside the package and does not depend onwheelresolving symlinks when building.I have moved to the hatch build system, which has some advantages. This is a plugin-oriented build-system, which means it should be fairly easy for us to find or write additional tools if our needs change. The hatch-vcs plugin wraps
setuptools_scmwith only minor changes to the configuration needed.One additional nice feature of hatch is that you can set different file include/exclude rules for sdists and wheels. In principle, an sdist should be testable without resorting to the original repository, so I have never much liked that we remove a large chunk of data. This allows us to exclude the
fmriprep/data/testsdirectory only in the wheel. This preserves our 5.5MB wheel while allowing the sdist to grow to the 30MB monstrosity that it ought to be.