MAINT: move to Flit build backend

[agoose77]

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.

[welcome]

Thanks for submitting your first pull request! You are awesome! 🤗

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! 🎉

[agoose77]

@mmcky do you have any spare cycles to look at merging this? 😄

[mmcky]

@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.

[agoose77]

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!

[chrisjsewell]

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?

[agoose77]

@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.

[chrisjsewell]

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?

[chrisjsewell]

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

[agoose77]

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.

[mmcky]

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

[agoose77]

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 ;)

[codecov]

Codecov Report

Merging #98 (7eeaf3d) into master (0113e03) will not change coverage.
The diff coverage is 100.00%.

Additional details and impacted files

@@           Coverage Diff           @@
##           master      #98   +/-   ##
=======================================
  Coverage   93.21%   93.21%           
=======================================
  Files           4        4           
  Lines         398      398           
=======================================
  Hits          371      371           
  Misses         27       27           

Flag	Coverage Δ
pytests	93.21% <100.00%> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Files	Coverage Δ
sphinx_jupyterbook_latex/events.py	88.46% <100.00%> (ø)
sphinx_jupyterbook_latex/nodes.py	98.55% <ø> (ø)
sphinx_jupyterbook_latex/transforms.py	92.54% <100.00%> (ø)

[agoose77]

In order to unblock main and reflect our changing maintenance schedules, I'm merging this as part of restoring CI.

[welcome]

Congrats on your first merged pull request in this project! 🎉


Thank you for contributing, we are very proud of you! ❤️