Migrated setuptools configuration to pyproject.toml.

[claudep]

No description provided.

[pauloxnet]

From a quick review, it seems fine to me 👍🏻

[nessita]

I will check these new instructions during the incoming release (early April).

/remind me to test this PR on April 2nd

[github-actions]

@nessita set a reminder for 4/2/2024

[github-actions]

👋 @nessita, test this PR

[ngnpope]

Generally LGTM

[claudep]

Thanks Nick! All suggestions applied.

[claudep]

Sorry, I messed up at some point. Now it should be better.

[claudep]

Mmmh, looks like deleting the find line is disturbing the tests. I'll try reintroduce it.

[ngnpope]

Yeah. I'll have to have a look next week at the details of how auto-discovery behaves.

[nessita]

I haven't tested this yet because the previous release was the "pair with Sarah" release and I prioritized showing the current flow.

/remind me to recheck this work on May 6th

[github-actions]

@nessita set a reminder for 5/6/2024

[github-actions]

👋 @nessita, recheck this work

[adamchainz]

Can we retitle this “Migrated setuptools configuration to pyproject.toml.”? That’s the major change here, using build is orthogonal (and could even be a second commit).

[ngnpope]

I was having a detailed look at this last night and there are some things that need tweaking. Will try to update with something soon.

[ngnpope]

Other than the things below I also saw the following warning in the output both before and after:

warning: no previously-included files matching '__pycache__' found anywhere in distribution

It seems that we should be able to remove global-exclude __pycache__ from MANIFEST.in.

Also, as we now depend on setuptools>=61 and given that setup.py install has been deprecated since v58.3.0 in October 2021, I think we can consider removing setup.py in its entirety. (It contains a bunch of workarounds to avoid overlaying an existing install which is no longer really applicable.)

[ngnpope]

@claudep Did you have any thoughts on these comments?

[claudep]

Oh sorry, missed it. I just pushed commits with your suggestion.

[ngnpope]

Also, as we now depend on setuptools>=61 and given that setup.py install has been deprecated since v58.3.0 in October 2021, I think we can consider removing setup.py in its entirety. (It contains a bunch of workarounds to avoid overlaying an existing install which is no longer really applicable.)

Another reason in favour of this is that it is relying on distutils still which has been removed from Python 3.12+ and is now a deprecated part of setuptools.

[nessita]

@ngnpope Hey there, we have a new release in a week (5.1 beta release), would you have some time to re-review this PR before then to consider merging this work and using it in that release? Thank you.

[ngnpope]

@nessita I'm basically happy with this, but am aware that the filename casing is still an issue:

$ git clean -fdx
$ python -m build
...
Successfully built django-5.1.dev20240523062023.tar.gz and Django-5.1-py3-none-any.whl

As I said before, I don't think we get a choice in the sdist filename. What's more confusing is why the wheel filename is still uppercased as I thought the whole point of PEP 625 was to align the naming to match the wheel filename convention... 🤔

We could, I guess, change the project name to be lowercased:

[project]                                                                                                               
name = "django"                                                                                                                                                

Which would then produce something consistent:

$ git clean -fdx
$ python -m build
...
Successfully built django-5.1.dev20240523062023.tar.gz and django-5.1-py3-none-any.whl

But this would change the casing of the name on PyPI itself. I don't know if that's a problem, but it sidesteps all of these normalization-related issues by being already normalized.

[ngnpope]

What's more confusing is why the wheel filename is still uppercased as I thought the whole point of PEP 625 was to align the naming to match the wheel filename convention... 🤔

It seems that there is a bug and the wheel filename should be lowercased according to this:

https://packaging.python.org/en/latest/specifications/binary-distribution-format/#escaping-and-unicode

More reading:

• setuptools ==69.3.0 builds my-package CLI as my_package (69.2.0 would build my-package CLI as my-package pypa/setuptools#4300 (comment)
• pypa/packaging.python.org@6d4efbc
• [BUG] Wheel naming is not following PEP 491 convention pypa/setuptools#3777

Urgh. What a mess.

TL;DR: This is good to go as the filename problem existed before switching to pyproject.toml anyway. You have two options - pin to setuptools>=61.0.0,<69.3.0 until setuptools is fixed to produce correct wheel filenames or switch to name = "django" to pre-normalize the name.

[nessita]

TL;DR: This is good to go as the filename problem existed before switching to pyproject.toml anyway. You have two options - pin to setuptools>=61.0.0,<69.3.0 until setuptools is fixed to produce correct wheel filenames or switch to name = "django" to pre-normalize the name.

Thank you so much @ngnpope for the complete summary. My preference is to pin setuptools, so we can merge this and progress this modernization without disrupting the project name and the binary casing. One question though: from my experiments, we need setuptools<67 to avoid any name case change. But you are proposing <69.3.0 so I wanted to double check with you about the proper upper threshold.

[ngnpope]

One question though: from my experiments, we need setuptools<67 to avoid any name case change. But you are proposing <69.3.0 so I wanted to double check with you about the proper upper threshold.

v63.9.0 introduced the changes that affected the filename, so I think the bounds I gave were correct? (It's what worked for me.)

[nessita]

One question though: from my experiments, we need setuptools<67 to avoid any name case change. But you are proposing <69.3.0 so I wanted to double check with you about the proper upper threshold.

v63.9.0 introduced the changes that affected the filename, so I think the bounds I gave were correct? (It's what worked for me.)

I'm assuming you meant v69.3.0 :-)
I tested again with a clean venv and you are correct, pip install "setuptools>=61.0.0,<69.3.0" allowed me to build these binaries:

-rw-r--r-- 1 nessita nessita  8200954 jun 19 10:22 Django-5.2.dev20240618152543-py3-none-any.whl
-rw-r--r-- 1 nessita nessita 10742249 jun 19 10:22 Django-5.2.dev20240618152543.tar.gz

So I think we are good to go!

[nessita]

Thank you everyone, this looks good. I have tested this in a clean environment and I have updated our "ad-hoc" release script. I will push a cleanup for what I think is a missed replace and then I'll merge:

docs/internals/contributing/writing-code/coding-style.txt:49:  ``setup.cfg`` file contains...