search

kevin1024 / vcrpy

Automatically mock your HTTP interactions to simplify and speed up testing
MIT License
2.72k stars 388 forks source link

Migrate to declarative Python package config #767

Open deronnax opened 1 year ago

deronnax commented 1 year ago

workflow approval plz 🥺

deronnax commented 11 months ago

@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 commented 11 months ago

@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 https://github.com/hartwork/sandwine/pull/20/commits/c260763a1c019cf7c11757b027a17f37b74e7a61 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 commented 11 months ago

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 commented 11 months ago

@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 commented 11 months ago

@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 :+1:

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 commented 8 months ago

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

kevin1024 commented 8 months ago

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 commented 8 months ago

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 commented 6 months ago

@kevin1024 can we get a go :) ?

deronnax commented 4 months ago

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