You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
.github/workflows/constraints.txt pins pip, poetry, virtualenv, nox, and nox-poetry but not pipx. pipx is the main installer for GA tests, and it has been running at whatever version GA setup-python gives.
I don't believe pinning installation packages is a good idea for most packages. Version control of these utilities is under user, not app, control. Pinning these packages to an old version results in testing possibly being out of step with the installation most users will experience. As a developer, I care whether doesn't work on GA because of pipx dependencies, but I don't really care what those dependencies are.
Worse still, current versions are system-dependent, and the <constraints.txt> mechanism has no way of encoding this. I found this problem because the latest virtualenv under Linux and MacOS is ahead of what is working under Windows. Testing installation with virtualenv pinned to the older one that works under Windows is not what most users will experience, while pinning it to the current one breaks Windows testing.
Getting rid of the pinning results in six fewer constraints to be updated. It also somewhat simplifies tests.yml and release.yml.
While we are at it, release.yml uses pip, not pipx, although that doesn't really matter.
Also while we are at it, although caching of poetry is supported by setup-python, the timings I have done show no advantage and that caching complicates installation by a lot under any python version but the current default.
I recommend no pinning of installation packages.
The text was updated successfully, but these errors were encountered:
.github/workflows/constraints.txt pins pip, poetry, virtualenv, nox, and nox-poetry but not pipx. pipx is the main installer for GA tests, and it has been running at whatever version GA setup-python gives.
I don't believe pinning installation packages is a good idea for most packages. Version control of these utilities is under user, not app, control. Pinning these packages to an old version results in testing possibly being out of step with the installation most users will experience. As a developer, I care whether doesn't work on GA because of pipx dependencies, but I don't really care what those dependencies are.
Worse still, current versions are system-dependent, and the <constraints.txt> mechanism has no way of encoding this. I found this problem because the latest virtualenv under Linux and MacOS is ahead of what is working under Windows. Testing installation with virtualenv pinned to the older one that works under Windows is not what most users will experience, while pinning it to the current one breaks Windows testing.
Getting rid of the pinning results in six fewer constraints to be updated. It also somewhat simplifies tests.yml and release.yml.
While we are at it, release.yml uses pip, not pipx, although that doesn't really matter.
Also while we are at it, although caching of poetry is supported by setup-python, the timings I have done show no advantage and that caching complicates installation by a lot under any python version but the current default.
I recommend no pinning of installation packages.
The text was updated successfully, but these errors were encountered: