BLD: simplify build-time requirements with flit-core #601
Conversation
neutrinoceros
force-pushed
the
bld/flit
branch
from
14351c8 to
5682b47
Compare
neutrinoceros
force-pushed
the
bld/flit
branch
from
5682b47 to
6a66e57
Compare
cphyc
left a comment
cphyc
left a comment
There was a problem hiding this comment.
I'd be in favour of this, especially given that I value your knowledge in managing these repos.
To quote their website:
Make the easy things easy and the hard things possible is an old motto from the Perl community. Flit is entirely focused on the easy things part of that, and leaves the hard things up to other tools.
| ] | ||
|
|
||
| build-backend = "setuptools.build_meta" | ||
| requires = ["flit_core >=3.11,<4"] |
There was a problem hiding this comment.
Version 4 doesn't exist yet, so who knows if it'll be compatible ?
There was a problem hiding this comment.
I'm just wondering why there is a difference compared to the suggested config on the flit website (https://flit.pypa.io/en/stable/pyproject_toml.html#build-system-section).
There was a problem hiding this comment.
There... isn't ? At least I don't see any
There was a problem hiding this comment.
Ha! It looks like not only LLMs have hallucinations sometimes, my apologies :/ !
There was a problem hiding this comment.
Ah, found it again. There is a difference when compared to their latest (rather than stable) version of the doc (https://flit.pypa.io/en/latest/pyproject_toml.html#build-system-section). But pinning <4 looks good to me.
There was a problem hiding this comment.
Interesting. I ended up learning there's a roadmap for flit 4.0 at pypa/flit#673
Welp, it'll be easy enough to upgrade once it's there, but thanks for noticing this !
2 participants
I don't think the current activity on this repo justifies the added complexity and potential instability that comes with
setuptools-scm, and setuptools itself, while heroically maintained throughout the years, is a complex beast I'd rather avoid every time a simpler alternative exists.flit-coreis just that. It has already being used in most of my pure-python repos (includingyt-project/cmyt) for about a year now and I didn't encounter any issue, so I'm proposing to make the switch in unyt too.