Move towards declarative setup.cfg

[venthur]

This fix moves most of the stuff from setup.py to setup.cfg. (Closes: #6501)

I accidentally referenced the wrong bug in one commit, as I thought was fixing this issue for setuptools. Anyways, the fix also applies to PIP. I couldn't migrate the version to setup.cfg, as we can't just use attr: src.pip.__version__ here.

[uranusjr]

I’d expect attr: pip.__version__ to work; otherwise it seems like an oversight that setuptools should fix.

[venthur]

But which version will it take then? The one from the package-to-be-installed or the one from the package-already-installed?

[uranusjr]

The to-be-installed one, of course! 😄 This is not specific to pip either—the same happens when you upgrade a package (i.e. install a module into an environment that already has a module of the same name).

[venthur]

Already fixed -- this also removed a lot of now-unused code from setup.py.

[pradyunsg]

What version of setuptools added support for setup.cfg?

pip should be on the tail end of adopters for functionality since anyone with an existing install too old won't be able to upgrade seamlessly.

[pradyunsg]

Good morning me, don't close PRs when you want to comment on them.

[venthur]

Can we restart the AppVeyour test?

[dholth]

does setuptools support receiving its setup() parameters from pyproject.toml yet?

[RonnyPfannschmidt]

no

[cjerdonek]

does setuptools support receiving its setup() parameters from pyproject.toml yet?

It looks like this is the issue for that: pypa/setuptools#1688 (and also pypa/setuptools#1160)

[pradyunsg]

I'm gonna take the liberty of closing this on the basis of rationale provided in #6501 just now.

To be clear, I am not forcing my stated position there and will be more than happy to reopen this PR, if we're going to do this. I do think folks will agree though so I'm potentially reducing future work for maintainers by doing this eagerly.