migrate packaging to pyproject.toml

[deronnax]

Just an initiative of my own.

Don't forget to squash merge the PR.

[deronnax]

OK, it's almost ready except:

• It can't work on python 3.6 because having setuptools being able to read metadata from pyproject.toml requires setuptools > 61.2, which does not support python 3.6 anymore.
• I need to figure out what is conftest.py doing with the package_root

[terencehonles]

• I need to figure out what is conftest.py doing with the package_root

This is unrelated to your PR and I fixed it with #9129

[deronnax]

Wow. It works indeed. Thank you so much.

[auvipy]

We need to hold this off for now. As we got other priorities.

[deronnax]

Sure. A vague estimation of when it would become envisageable ?

[deronnax]

To merge after #9210, I hope.

[deronnax]

watch-out: this PR is intended to be squash-merged

[tomchristie]

So... this is a good example of a nice little pr that's a bit stalled. I don't really have any extra bandwidth to keep this moving, given existing commitments. Should we be having a discussion about getting the project into jazzband.co so that we've got a lower barrier of entry for new maintainers?

[deronnax]

Hey, that's a very interesting decision that is (way) beyond the scope of my humble little PR. Maybe let's open a dedicated issue ou GitHub discussion?

[sevdog]

Can we reconsider this in the priorities of the project to reflect the latest changes in the Python environment and the problem which was caused by setuptools==72.0.0 (aka: libraries which use legacy and long deprecated setup/build configurations)?

[deronnax]

@tomchristie that's ready to merge (let's not forget to squash merge).

[tomchristie]

@deronnax Id be happy to see a release, tho someone else would need to take the lead on it.

[auvipy]

looks better then before, but I want to do some more study before merging this

[terencehonles]

A couple comments I had when looking over this change

[terencehonles]

Is there a reason you're disabling namespaces? I believe you can also just specify the packages directly since there is only one:

Suggested change

	[tool.setuptools.packages.find]
	namespaces = false
	packages = ["rest_framework"]

[deronnax]

I disabled them because they were disabled originally, using find_packages in the setup.py instead of find_namespace_packages. I tried your suggestion but it broke the CI, so I reverted it.

[terencehonles]

I see, thanks for trying. It appears I misunderstood the default behavior for nested packages.

You'd need to try the following:

Suggested change

	[tool.setuptools.packages.find]
	namespaces = false
	[tool.setuptools.packages.find]
	include = ["rest_framework*"]

I used the build module to build a wheel and with my original suggestion it was warning that the sub-packages were not being included, but with the include statement it worked as intended and bundled the sub-packages.

Do you mind running that by the CI?

[deronnax]

sure. But as it is changing the behavior, even if it works, I would like it in a separate PR :)

[terencehonles]

Well what you used doesn't match the original either, since you're missing the exclude so I'd just switch to the new style using include and you can leave off the namespace disabling or turn it off if you really prefer it to be off. I just don't think it needs to be off.

[deronnax]

@auvipy can you give a deadline at which you would have done this study? I think (and some other) that's it's pretty important PR and it should not get spiraled into oblivion.

[terencehonles]

It looks like my comment was stuck pending 🤦

[terencehonles]

Well what you used doesn't match the original either, since you're missing the exclude so I'd just switch to the new style using include and you can leave off the namespace disabling or turn it off if you really prefer it to be off. I just don't think it needs to be off.