Migrate to declarative Python package config

[deronnax]

No description provided.

[deronnax]

workflow approval plz 🥺

[hartwork]

@deronnax before we go into details, I'd like to ask for the motivation behind this change when we could (and will eventually) migrate to build and pyproject.toml. Please help me see the value in this intermediary stage. Thank you!

[deronnax]

@hartwork pyproject.toml is a bit of a bigger leap. initially I offered direct move to pyproject.toml but people were reluctant to do the leap. But if you are willing, I will do the conversion straight to pyproject.toml.

[hartwork]

@hartwork pyproject.toml is a bit of a bigger leap. initially I offered direct move to pyproject.toml but people were reluctant to do the leap. But if you are willing, I will do the conversion straight to pyproject.toml.

@deronnax thanks for your reply!

I'm trying to find a previous conversion about it up here, but I fail to find any. Have a link? Maybe it was even me who reluctant about it, to some extent I still am, but simplified personally I'll be good with any of setup.py, setup.cfg and pyproject.toml here if the conversion is lossless and has some motivation.

But I'm not making the release files. @kevin1024 will you be okay to start using the build command for creating VCR.py release files (rather than python3 setup.py ...`)? This diff hartwork/sandwine@c260763 is a demo of what may come here if you say "yes" to that. What do you think?

@jairhenrique do you have any stakes in the setup.py VS setup.cfg VS pyproject.toml future discussion?

[jairhenrique]

Following PEP 621, projects metadata should be put on pyproject.toml file.

Using the pypa tool hatch, following this steps, hatch automatically create or update the pyproject.toml file.

pip install hatch
hatch new --init

[deronnax]

@hartwork sorry I meant "people in general on GitHub", not the vcrpy community. Some people don't feel to do the jump to pyproject.toml yet.
I did the pyproject.toml conversion on today's master, and restored the gone comments.

[hartwork]

@hartwork sorry I meant "people in general on GitHub", not the vcrpy community. Some people don't feel to do the jump to pyproject.toml yet.

@deronnax I understand, thanks for the clarification 👍

I did the pyproject.toml conversion on today's master, and restored the gone comments.

Thanks! The CI may(?) need adjustment to use build and all, but before we know if @kevin1024 is on board with this direction there is a risk for wasting your time, just to avoid potential disappointment.

[deronnax]

@kevin1024 what's your stance on the subject? I can also do the move to the pyproject.toml if you prefer.

[kevin1024]

Hello! I’m afraid I haven’t been following new developments in Python packaging very closely for awhile now. My general opinion on this is: if it increases compatibility with the newer packaging ecosystem without breaking compatibility with any of our existing environments we support, then I am in favor.

There are a number of Linux distributions that package VCR.py from source. I believe if we make this change it may also affect their build scripts, so ideally we would also coordinate with those maintainers.

[hartwork]

Hello! I’m afraid I haven’t been following new developments in Python packaging very closely for awhile now. My general opinion on this is: if it increases compatibility with the newer packaging ecosystem without breaking compatibility with any of our existing environments we support, then I am in favor.

@kevin1024 that seems to be the case, I think you're in favor then.

Regarding need to migrate https://packaging.python.org/en/latest/discussions/setup-py-deprecated/ could be of interest, but it's not meant as an argument to not migrate.

There are a number of Linux distributions that package VCR.py from source. I believe if we make this change it may also affect their build scripts, so ideally we would also coordinate with those maintainers.

Speaking with my Gentoo downstream maintainer hat on here: Distros already need to support various ways to build Python software, use of pyproject.toml should not cause trouble there or the distro would be in big trouble. At least as long as mainstream values for build-system are used, see https://projects.gentoo.org/python/guide/distutils.html#pep-517-build-systems maybe for a list of backends supported in Gentoo. I personally don't expect problems o that front.

[deronnax]

@kevin1024 can we get a go :) ?

[deronnax]

Having this merged when it was time would have avoided #855 because vcrpy uses 4 years-deprecated setup.py test command and setuptools removed it today, breaking instantly most CI using vcrpy.

[pjonsson]

I don't speak for the package, but if this gets wind in the sails now and gets merged, there's a third case for urllib3 added to setup.py after this PR was created.

[LewisCowlesMotive]

So what I don't like about this approach, is that it does not attempt to lock. If the non-locking is to preserve some old use-cases for python 3.8, then I suggest making those explicit.

This wild west, "go grab whatever versions of these packages!" is what caused the most breakages, and uncertainty, because it's harder for a dependency resolver to pick the right thing for all the packages.

[hartwork]

@LewisCowlesMotive that's likely a misunderstanding: pyproject.toml is meant to not lock, to be compatible and play well with the neighbors in a pot of multiple Python packages: a virtualenv, a Linux distro, Homebrew etc. Else you quickly have packages that can no longer be installed side by side. The place to lock is requirements.txt or something similar for a single deployment, not a package ecosystem.

[LewisCowlesMotive]

I don't know if you are misinterpreting my request to have version constraints as asking to make pyproject.toml a lock-file.

It's the lack of any version information I am complaining about to be clear.

[graingert]

Let's leave this PR to migrate the config as is without changes, we can have a follow up PR to change the config

[LewisCowlesMotive]

What are the benefits of the PR? It declares the same things as the imperative code. Is that the benefit?

[graingert]

Yes