Migrate to declarative Python package config #767

deronnax · 2023-09-12T08:55:57Z

No description provided.

deronnax · 2023-09-12T08:56:38Z

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!

setup.cfg

deronnax · 2023-12-11T13:28:51Z

@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 · 2023-12-11T16:04:16Z

@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 · 2023-12-11T16:44:22Z

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 · 2023-12-13T17:40:40Z

@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 · 2023-12-13T18:05:29Z

@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 · 2024-03-14T13:36:03Z

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

kevin1024 · 2024-03-16T09:28:52Z

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 · 2024-03-16T12:07:35Z

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 · 2024-05-27T09:50:25Z

@kevin1024 can we get a go :) ?

deronnax · 2024-07-29T10:49:31Z

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 · 2024-07-29T19:00:27Z

pyproject.toml

+    # https://github.com/kevin1024/vcrpy/pull/699#issuecomment-1551439663
+    "urllib3 <2; python_version <'3.10'",
+    # https://github.com/kevin1024/vcrpy/pull/775#issuecomment-1847849962
+    "urllib3 <2; platform_python_implementation =='PyPy'",


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 · 2024-07-31T07:10:26Z

pyproject.toml

+    "PyYAML",
+    "wrapt",
+    "yarl",
+    # Support for urllib3 >=2 needs CPython >=3.10


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.

@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.

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.

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

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

deronnax marked this pull request as draft September 12, 2023 08:56

hartwork requested changes Dec 8, 2023

View reviewed changes

setup.cfg Outdated Show resolved Hide resolved

setup.cfg Outdated Show resolved Hide resolved

migrate setup.py to pyproject.toml

f6c46cc

deronnax force-pushed the declarative-package-config branch from 6c96112 to f6c46cc Compare December 13, 2023 17:35

deronnax marked this pull request as ready for review December 13, 2023 17:35

hartwork changed the title ~~migrate to declarative package config~~ Migrate to declarative Python package config Dec 13, 2023

pjonsson mentioned this pull request Jul 29, 2024

fix: use poetry, not old setuptools #859

Closed

pjonsson reviewed Jul 29, 2024

View reviewed changes

LewisCowlesMotive reviewed Jul 31, 2024

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Migrate to declarative Python package config #767

Migrate to declarative Python package config #767

deronnax commented Sep 12, 2023

deronnax commented Sep 12, 2023

hartwork left a comment •

edited

Loading

deronnax commented Dec 11, 2023

hartwork commented Dec 11, 2023 •

edited

Loading

jairhenrique commented Dec 11, 2023

deronnax commented Dec 13, 2023

hartwork commented Dec 13, 2023 •

edited

Loading

deronnax commented Mar 14, 2024

kevin1024 commented Mar 16, 2024

hartwork commented Mar 16, 2024 •

edited

Loading

deronnax commented May 27, 2024

deronnax commented Jul 29, 2024 •

edited

Loading

pjonsson Jul 29, 2024

LewisCowlesMotive Jul 31, 2024

hartwork Jul 31, 2024 •

edited

Loading

LewisCowlesMotive Aug 1, 2024

graingert Aug 1, 2024

LewisCowlesMotive Aug 2, 2024

graingert Aug 2, 2024

Migrate to declarative Python package config #767

Are you sure you want to change the base?

Migrate to declarative Python package config #767

Conversation

deronnax commented Sep 12, 2023

deronnax commented Sep 12, 2023

hartwork left a comment • edited Loading

Choose a reason for hiding this comment

deronnax commented Dec 11, 2023

hartwork commented Dec 11, 2023 • edited Loading

jairhenrique commented Dec 11, 2023

deronnax commented Dec 13, 2023

hartwork commented Dec 13, 2023 • edited Loading

deronnax commented Mar 14, 2024

kevin1024 commented Mar 16, 2024

hartwork commented Mar 16, 2024 • edited Loading

deronnax commented May 27, 2024

deronnax commented Jul 29, 2024 • edited Loading

pjonsson Jul 29, 2024

Choose a reason for hiding this comment

LewisCowlesMotive Jul 31, 2024

Choose a reason for hiding this comment

hartwork Jul 31, 2024 • edited Loading

Choose a reason for hiding this comment

LewisCowlesMotive Aug 1, 2024

Choose a reason for hiding this comment

graingert Aug 1, 2024

Choose a reason for hiding this comment

LewisCowlesMotive Aug 2, 2024

Choose a reason for hiding this comment

graingert Aug 2, 2024

Choose a reason for hiding this comment

hartwork left a comment •

edited

Loading

hartwork commented Dec 11, 2023 •

edited

Loading

hartwork commented Dec 13, 2023 •

edited

Loading

hartwork commented Mar 16, 2024 •

edited

Loading

deronnax commented Jul 29, 2024 •

edited

Loading

hartwork Jul 31, 2024 •

edited

Loading