chore: include Python 3.11 classifier & testing

[henryiii]

Also, is there a reason that there is an upper cap on argcomplete and colorlog? Besides all the other reasons to avoid upper caps in the Python ecosystem unless they are truly well thought out and necessary, this is also out of date on the conda recipe. (It's possible I asked before and have forgotten why).

[henryiii]

Also removing check-manifest, since this doesn't use setuptools anymore!

[FollowTheProcess]

Do we not need MANIFEST.in for the *.jinja files? My understanding is setuptools needs a bit of help defining the files to include with packaging unlike e.g. flit which by default includes everything checked into git?

As for upper limits I'm not entirely sure tbh, they've always been like that since I started contributing AFAIK, I'm up for removing the upper limits unless there's a strong reason not to

[henryiii]

Ahh, I thought you were using hatchling:

nox/pyproject.toml

Lines 2 to 5 in 56e5582

	build-backend = "setuptools.build_meta"
	requires = [
	"setuptools>=61",
	]

Didn't realize you were still on setuptools, but just using the pypyproject.toml form. Hatchling doesn't need help, and is quite a bit faster and has better error messages. But yes, then MANIFEST.in probably is needed. I think we should check the SDist & wheel contents, though - setuptools got smarter about package discovery so worth checking. (Hatchling uses .gitignore, which is brilliant IMO).

[henryiii]

A few science packages have started capping setuptools < 60 because NumPy's recommending it for anyone using numpy.distutils, which they would rather remove than update to the new distutils inside setuptools 60+. I've been fighting that capping (you can just set a variable to get the old distutils for now), but just a FYI. In theory, nox should be in a fairly clean environment and make the environments that have all the libraries in them.

Edit: Just realized this only matters when building the wheel. 🤦

[henryiii]

Oh, and Flit only uses Git if you are not using standard tools like pypa/build, but only it's own special flit CLI. Otherwise it needs lots of help too (which is horrible, IMO - flit packages may not conform to standards). Hatchling uses gitignore, so it works regardless of if git is even installed.

[henryiii]

No change that I see when diff'ing the SDist contents. The ninja & py.typed are still there. It's because you use include_package_data=true - anything explicitly marked as package data (or picked up by this auto flag) will also be marked for inclusion in the SDist. MANIFEST.in is only for things that go in the SDist but not the wheel.

FYI, tried running this using hatchling too. Saves a couple of seconds, and way less verbose build output. Doing the diff on the SDist, hatchling clears the ownership UUIDs, which is nice. And the wheel diff it removes top_level.txt and places the LICENSE in licenses/LICENSE. Also it needed zero tool.<stuff>, while setuptools still has three lines. Might make a PR as a demo.

origsd.txt
origwl.txt
nomanisd.txt
nomaniwl.txt
hatchsd.txt
hatchwl.txt

[FollowTheProcess]

Okay cool, thanks @henryiii python packaging continues to confuse me even after years of doing it! I'm on board with switching to hatchling, if we're doing that I'd suggest merging the two PR's so it contains both changes? Or at least merge the hatchling one first

[henryiii]

I'd go for this one first - it's nice to get Python 3.11 testing, while Hatchling is completely optional. I can easily rebase (and it's a matching change - a file removed). And that one will be on hold for a while; I have a question about package extra normalization - Hatchling seems to be using PEP 685 to normalize the extra names, but pip is not using PEP 685 when looking for them.

[FollowTheProcess]

Okay works for me 👍🏻