(From a users perspective). So I realize packaging is almost like a side-hustle for pyproject.toml. But it also seems partly a regression over setup.py, since most 517 implementations hinge on static declarations.¹
Specifically there’s seemingly no way to do version lookups anymore. You know, all the fiddly little ways (import/regex/perl) people have been using to extract a
version from modules. → Which seems
odd, since it’s such a cheap feature to standardize. And it wouldn’t even have to be stellar, a 80/20 solution would do just fine.
- As in:
version-extract-from = "src/init.py"simply reads a script, and regexes the first semver/pep440/float out of it.
- Didn’t even have to be a context-sensitive lookup. Because for fringe cases, a static/handicrafted pyproject.toml was still an option.
- Obviously pep621 is frozen now, but what are the chances of any such support appearing in the build backends? ²
There’s nothing wrong with a bit of meta data duplication. There’s also no difference between setup.py and pyproject.toml when it comes to name= or description= etc. Those are rarely, if ever updated. While significant changes like new dependencies do warrant a commit artifact.
But like readme=, the version= field is clearly different. Might not matter to applications, but for e.g. smaller libraries disjoining the version field from the source seems a clutch (really just conveniences
Or are there any plans for a _meta_data_update API hook / build chain plugins? - Like, somewhat of a healthy middle ground between sticking with setuptools vs. building a whole new build tool. ³
¹ TBH I haven’t looked into
prepare_metadata_for_build_wheel much. Seems intend for all-or-nothing rather than partial meta population though. And setuptools-scm doesn’t seem to use any such hooks either.
² Just noticed
flit does the sensible thing and honors
__version__ from the init module at least. (This is one of those features that might warrant a tabular overview in the packaging user guide.)
³ Of course I can just keep my Makefile rules with the current backends, but that sort of the defeats the purpose of pep518 really.