PyPI should include PEP 440-compliant version strings for including in install_requires
Figuring out versioning is hard. PyPI should encourage semver by including PEP 440 version strings that you can copy and paste into install_requires. This'll encourage module authors to do their best to follow semver. And also it means I can copy and paste the things and my code won't silently break because I didn't specify dependency versioning. More specifically, it'll just have me specify dependency versioning by default.
On Sun, 9 Feb 2020 at 14:39, Soni L. <fakedme+py@gmail.com> wrote:
Figuring out versioning is hard. PyPI should encourage semver by including PEP 440 version strings that you can copy and paste into install_requires.
I don't understand what you mean by **PyPI** including version strings. PyPI just publishes the data the module contains. Do you mean the packaging documentation, or PyPA, or something?
This'll encourage module authors to do their best to follow semver.
We don't dictate how projects choose their versioning scheme. Some use semver, others don't, it's a project choice. And PEP 440 versions are explicitly designed to support non-semver versioning schemes like calver, so I don't even see how PEP 440 versions would encourage use of semver anyway. Paul
On Sun, Feb 9, 2020, 11:03 AM Paul Moore <p.f.moore@gmail.com> wrote:
On Sun, 9 Feb 2020 at 14:39, Soni L. <fakedme+py@gmail.com> wrote:
Figuring out versioning is hard. PyPI should encourage semver by including PEP 440 version strings that you can copy and paste into install_requires.
I don't understand what you mean by **PyPI** including version strings. PyPI just publishes the data the module contains. Do you mean the packaging documentation, or PyPA, or something?
I think they mean that instead of e.g. https://pypi.org/project/six/ just showing `pip install six`, it should also show example install_requires values. E.g. `install_requires: ['six~=1.14.0']`. Or maybe a dropdown where you select the compatibility you want and and it formats the version string. This does seem like a good way to encourage people to specify or at least think about versioned dependencies, although I wonder how many people look at pypi when specifying their dependencies in `install_requires`?
On Mon, Feb 10, 2020 at 6:09 PM Matthew Einhorn <moiein2000@gmail.com> wrote:
On Sun, Feb 9, 2020, 11:03 AM Paul Moore <p.f.moore@gmail.com> wrote:
On Sun, 9 Feb 2020 at 14:39, Soni L. <fakedme+py@gmail.com> wrote:
Figuring out versioning is hard. PyPI should encourage semver by including PEP 440 version strings that you can copy and paste into install_requires.
I don't understand what you mean by **PyPI** including version strings. PyPI just publishes the data the module contains. Do you mean the packaging documentation, or PyPA, or something?
I think they mean that instead of e.g. https://pypi.org/project/six/ just showing `pip install six`, it should also show example install_requires values. E.g. `install_requires: ['six~=1.14.0']`. Or maybe a dropdown where you select the compatibility you want and and it formats the version string.
This does seem like a good way to encourage people to specify or at least think about versioned dependencies, although I wonder how many people look at pypi when specifying their dependencies in `install_requires`?
-1. I don't want everyone to pin to an exact version just because it's the obvious copy/paste command. That's what happens all the time in the Node.js world, and the result is a constant battle to get everyone to upgrade their packages, because they've unnecessarily pinned them. Instead, encourage everyone to install *without* version numbers. If that results in a package being broken because of a backward-incompatible change, that's the fault of the package, and it SHOULD be seen as a problem. ChrisA
On 10Feb2020 18:26, Chris Angelico <rosuav@gmail.com> wrote:
On Mon, Feb 10, 2020 at 6:09 PM Matthew Einhorn <moiein2000@gmail.com> wrote:
On Sun, Feb 9, 2020, 11:03 AM Paul Moore <p.f.moore@gmail.com> wrote:
On Sun, 9 Feb 2020 at 14:39, Soni L. <fakedme+py@gmail.com> wrote:
Figuring out versioning is hard. PyPI should encourage semver by including PEP 440 version strings that you can copy and paste into install_requires.
I use PEP440 version strings, but they're not semver strings. [...]
I think they mean that instead of e.g. https://pypi.org/project/six/ just showing `pip install six`, it should also show example install_requires values. E.g. `install_requires: ['six~=1.14.0']`. Or maybe a dropdown where you select the compatibility you want and and it formats the version string.
This does seem like a good way to encourage people to specify or at least think about versioned dependencies, although I wonder how many people look at pypi when specifying their dependencies in `install_requires`?
-1. I don't want everyone to pin to an exact version just because it's the obvious copy/paste command. That's what happens all the time in the Node.js world, and the result is a constant battle to get everyone to upgrade their packages, because they've unnecessarily pinned them.
Instead, encourage everyone to install *without* version numbers. If that results in a package being broken because of a backward-incompatible change, that's the fault of the package, and it SHOULD be seen as a problem.
I'm with Chris here. Install without versions unless you've s specific requirement such as a feature to use or a bug/misfeature to avoid. I look on pinning as a tool for reproducability; if I've tested against my venv happily, my build/install should use the versions from its "pip freeze". Cheers, Cameron Simpson <cs@cskk.id.au>
On 2020-02-10 6:13 a.m., Cameron Simpson wrote:
On 10Feb2020 18:26, Chris Angelico <rosuav@gmail.com> wrote:
On Mon, Feb 10, 2020 at 6:09 PM Matthew Einhorn <moiein2000@gmail.com> wrote:
On Sun, Feb 9, 2020, 11:03 AM Paul Moore <p.f.moore@gmail.com> wrote:
On Sun, 9 Feb 2020 at 14:39, Soni L. <fakedme+py@gmail.com> wrote:
Figuring out versioning is hard. PyPI should encourage semver by including PEP 440 version strings that you can copy and paste into install_requires.
I use PEP440 version strings, but they're not semver strings.
I feel sorry for you
[...]
I think they mean that instead of e.g. https://pypi.org/project/six/ just showing `pip install six`, it should also show example install_requires values. E.g. `install_requires: ['six~=1.14.0']`. Or maybe a dropdown where you select the compatibility you want and and it formats the version string.
This does seem like a good way to encourage people to specify or at least think about versioned dependencies, although I wonder how many people look at pypi when specifying their dependencies in `install_requires`?
-1. I don't want everyone to pin to an exact version just because it's the obvious copy/paste command. That's what happens all the time in the Node.js world, and the result is a constant battle to get everyone to upgrade their packages, because they've unnecessarily pinned them.
Instead, encourage everyone to install *without* version numbers. If that results in a package being broken because of a backward-incompatible change, that's the fault of the package, and it SHOULD be seen as a problem.
I'm with Chris here. Install without versions unless you've s specific requirement such as a feature to use or a bug/misfeature to avoid.
I look on pinning as a tool for reproducability; if I've tested against my venv happily, my build/install should use the versions from its "pip freeze".
I still think PyPI should suggest/encourage using at least >= by default. for comparison Rust/Cargo enforces semver and altho you specify a dependency like tokio="0.2" it'll actually use any compatible version as defined by semver. there are many reasons to at least specify a minimum version. I see the reasons not to specify maximum versions tho.
Cheers, Cameron Simpson <cs@cskk.id.au> _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/W7F64I... Code of Conduct: http://python.org/psf/codeofconduct/
On 2020-02-10 9:15 a.m., Soni L. wrote:
[...]
I think they mean that instead of e.g. https://pypi.org/project/six/ just showing `pip install six`, it should also show example install_requires values. E.g. `install_requires: ['six~=1.14.0']`. Or maybe a dropdown where you select the compatibility you want and and it formats the version string.
This does seem like a good way to encourage people to specify or at least think about versioned dependencies, although I wonder how many people look at pypi when specifying their dependencies in `install_requires`?
-1. I don't want everyone to pin to an exact version just because it's the obvious copy/paste command. That's what happens all the time in the Node.js world, and the result is a constant battle to get everyone to upgrade their packages, because they've unnecessarily pinned them.
Instead, encourage everyone to install *without* version numbers. If that results in a package being broken because of a backward-incompatible change, that's the fault of the package, and it SHOULD be seen as a problem.
I'm with Chris here. Install without versions unless you've s specific requirement such as a feature to use or a bug/misfeature to avoid.
I look on pinning as a tool for reproducability; if I've tested against my venv happily, my build/install should use the versions from its "pip freeze".
I still think PyPI should suggest/encourage using at least >= by default. for comparison Rust/Cargo enforces semver and altho you specify a dependency like tokio="0.2" it'll actually use any compatible version as defined by semver.
there are many reasons to at least specify a minimum version. I see the reasons not to specify maximum versions tho.
fwiw, this works with non-semver versioning and basically any versioning that increments version numbers one way or another. the main benefit here is when adding a new dependency to an old project, so that it'll update the other dependencies as needed rather than giving you an error because the new dependency relies on new features not available in the version you're using.
Cheers, Cameron Simpson <cs@cskk.id.au> _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/W7F64I... Code of Conduct: http://python.org/psf/codeofconduct/
there are many reasons to at least specify a minimum version
Yes, but I think your proposal would encourage people to pin to the latest version as a minimum, which would be unfortunate. I like the maxim: “don’t pin a version unless you have a good reason, and you’ve thought about what version to pin to.” Once you’ve done that — the formatting of the version string is a light lift. -CHB -- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython
On 2020-02-10 2:59 p.m., Christopher Barker wrote:
there are many reasons to at least specify a minimum version
Yes, but I think your proposal would encourage people to pin to the latest version as a minimum, which would be unfortunate.
I like the maxim: “don’t pin a version unless you have a good reason, and you’ve thought about what version to pin to.” Once you’ve done that — the formatting of the version string is a light lift.
Then perhaps a mechanism to override the version check is in order. Also useful when playing around with forks, I guess. (we still can't override PIL, fwiw.)
-CHB
-- Christopher Barker, PhD
Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython
On Tue, Feb 11, 2020 at 5:00 AM Christopher Barker <pythonchb@gmail.com> wrote:
there are many reasons to at least specify a minimum version
Yes, but I think your proposal would encourage people to pin to the latest version as a minimum, which would be unfortunate.
I like the maxim: “don’t pin a version unless you have a good reason, and you’ve thought about what version to pin to.” Once you’ve done that — the formatting of the version string is a light lift.
Agreed. Pin only when you actually know why you're pinning. 1) You've just pushed to staging and done your testing. For the push to production, use "pip freeze" to lock in the deps. 2) You start using a cool new feature of something and need to make sure you have version X 3) There's a bug in version X.Y.Z but version X.Y-1.Q works, so you pin that pending a check of X.Y+1 or X.Y.Z+1 4) Etcetera. But *by default*, just grab the latest and don't mandate it. Most of the time, it won't matter, so don't create problems downstream. ChrisA
-----Original Message----- From: Chris Angelico <rosuav@gmail.com> Sent: 10 February 2020 18:16 To: python-ideas <python-ideas@python.org> Subject: [Python-ideas] Re: PyPI should include PEP 440-compliant version strings for including in install_requires On Tue, Feb 11, 2020 at 5:00 AM Christopher Barker <pythonchb@gmail.com> wrote:
there are many reasons to at least specify a minimum version
Yes, but I think your proposal would encourage people to pin to the latest version as a minimum, which would be unfortunate.
I like the maxim: “don’t pin a version unless you have a good reason, and you’ve thought about what version to pin to.” Once you’ve done that — the formatting of the version string is a light lift.
Agreed. Pin only when you actually know why you're pinning. 1) You've just pushed to staging and done your testing. For the push to production, use "pip freeze" to lock in the deps. 2) You start using a cool new feature of something and need to make sure you have version X 3) There's a bug in version X.Y.Z but version X.Y-1.Q works, so you pin that pending a check of X.Y+1 or X.Y.Z+1 4) Etcetera. But *by default*, just grab the latest and don't mandate it. Most of the time, it won't matter, so don't create problems downstream. ChrisA [Steve Barnes] Good points above! I know that this discussion is about pip requires versioning but I would like to add one point were it is important to pin to __exact__ releases for pipenv (not pip): - Always pin to specific releases in pipenv if you are using pipenv and travis, or other, CI/CT - this is because without an exact pin (i.e. with a * in the pipenv library list) the latest versions of libraries will be downloaded and when (not if) the unpinned library has been updated your tests will always fail even, for the most trivial change, until someone with the pipenv expertise updates the SHA list. (I had this recently with a change to a readme.txt file on a project). _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/S6NKQ3... Code of Conduct: http://python.org/psf/codeofconduct/
On 2/10/20 2:26 AM, Chris Angelico wrote:
On Mon, Feb 10, 2020 at 6:09 PM Matthew Einhorn <moiein2000@gmail.com> wrote:
On Sun, Feb 9, 2020, 11:03 AM Paul Moore <p.f.moore@gmail.com> wrote:
Figuring out versioning is hard. PyPI should encourage semver by including PEP 440 version strings that you can copy and paste into install_requires. I don't understand what you mean by **PyPI** including version strings. PyPI just publishes the data the module contains. Do you mean
On Sun, 9 Feb 2020 at 14:39, Soni L. <fakedme+py@gmail.com> wrote: the packaging documentation, or PyPA, or something?
I think they mean that instead of e.g. https://pypi.org/project/six/ just showing `pip install six`, it should also show example install_requires values. E.g. `install_requires: ['six~=1.14.0']`. Or maybe a dropdown where you select the compatibility you want and and it formats the version string.
This does seem like a good way to encourage people to specify or at least think about versioned dependencies, although I wonder how many people look at pypi when specifying their dependencies in `install_requires`?
-1. I don't want everyone to pin to an exact version just because it's the obvious copy/paste command. That's what happens all the time in the Node.js world, and the result is a constant battle to get everyone to upgrade their packages, because they've unnecessarily pinned them.
Instead, encourage everyone to install *without* version numbers. If that results in a package being broken because of a backward-incompatible change, that's the fault of the package, and it SHOULD be seen as a problem.
PyPI already shows a pinned installation snippet if you specify a particular version in the URL, which you must do to see a version that isn't the latest: https://pypi.org/project/coverage/4.5.4/ It shows unpinned when you look at a package without specifying a version: https://pypi.org/project/coverage --Ned.
participants (8)
-
Cameron Simpson -
Chris Angelico -
Christopher Barker -
Matthew Einhorn -
Ned Batchelder -
Paul Moore -
Soni L. -
Steve Barnes