Closed agoose77 closed 11 months ago
Thanks for submitting your first pull request! You are awesome! :hugs:
If you haven't done so already, check out EBP's Code of Conduct and our Contributing Guide, as this will greatly help the review process.
Welcome to the EBP community! :tada:
@mmcky do you have any spare cycles to look at merging this? :smile:
@agoose77 Super Sorry - this completely escaped my radar. I'll try and loop around to this soon. I'm not super familiar with flit but I'll give it a go.
At this point, I'd want to use Hatch; flit is increasingly looking to be the build-backend with zero dependencies as its selling point, rather than features. That is to say, there've been suggestions that flit-core's main use case will be underpinning all of the other PEP 517 build backends; repackagers can't use existing wheels, so they need to build everything from a single root build tool.
I started with Hatch here: 400c4a2
We'd need to rebase this PR, but I can do that if needs be!
flit is increasingly looking to be the build-backend with zero dependencies as its selling point, rather than features
just curious, why do you need features here though? This is a pure python package, so why complicate things?
@chrisjsewell not so much a need for features (particular not this repo!), but my guess is that flit-core
will be less widely used down the road for the average repo. As such, we'd do well to standardise on the derived build backends like Hatch or PDM across all of our projects to maintain consistency and ease.
I'm not hugely fussed here; if we don't want to make any inconsistencies at this juncture, we can pursue flit-core
in line with the rest of the repositories under this org, and migrate down the line if it seems appropriate.
but my guess is that flit-core will be less widely used down the road for the average repo.
I very much doubt that will be the case, and I haven't seen anything to suggest it. Is there somewhere that states this?
we'd do well to standardise on the derived build backends like Hatch or PDM across all of our projects to maintain consistency and ease.
Not fussed what you choose here really, but yeh I disagree with this, unless as mentioned there is something I am missing with regard to the flit roadmap
There are ongoing discussions about packaging over on the Discourse for Python. The first mention of this philosophical shift was here, but I've seen other comments scattered around IIRC.
Honestly I have not fully absorbed the move to flit
over the standard setuptools
packaging other than possibly simpler to maintain and easier to use (which are positives for sure). Given the majority of ExectuableBooks
is using flit
let's not diverge tools and stick with this one for now.
Thanks @agoose77 for the update on alternatives. I will have a quick read about Hatch
It's not a huge deal; as long as we're using a PEP 621-supporting backend, then it's not too tricky to change things at a later date ;)
Merging #98 (7eeaf3d) into master (0113e03) will not change coverage. The diff coverage is
100.00%
.
In order to unblock main and reflect our changing maintenance schedules, I'm merging this as part of restoring CI.
Congrats on your first merged pull request in this project! :tada:
Thank you for contributing, we are very proud of you! :heart:
This PR removes setuptools as our build backend in favour of Flit. This means we can move to using only
pyproject.toml
for all of our build information, and allows us to use modern packaging tools.NB This started out as a PR to use hatchling (hatch), but I moved to Flit to align with existing tools.