4 ms·

Interesting problem but I think it's more a problem in virtualenv, which don't use global site package by default, I'm surprised that it uses user site package

Interesting problem but I think it's more a problem in virtualenv, which don't use global site package by default, I'm surprised that it uses user site packages by default. However, installing every dependency in the same environment is also what distro package managers do, I don't see that as a recipe for disaster, it all depends how well the said packages are maintained in which case just upgrading them should fix whatever problem.

gjulianm 5y ago
> However, installing every dependency in the same environment is also what distro package managers do, I don't see that as a recipe for disaster, Distro packages are done in a way where it's hard to get conflicts. I haven't found an instance where python3-X and python3-Y can't be installed because one requires python3-Z v1.2 and the other python3-Z v2.1. With Python packages, that happens way more often. Also, distro package managers keep track of everything installed, while python ones (at least pip I'm 100% sure) don't. You could install a package which upgrades another one, and that breaks another that you had installed before and pip won't say a word.
- 1337shadow 5y ago
  > I haven't found an instance where python3-X and python3-Y can't be installed because one requires python3-Z v1.2 and the other python3-Z v2.1. With Python packages, that happens way more often. Exactly, because the packages were created/updated at a point in time were they were compatible: a distro ships python 3.x with packages of python modules that are compatible with python 3.x. Now if you as a user want to use a python package that works with python 3.y, you either have to wait, or install python 3.y, or use a container of python 3.y. Again, if all python package were up to date as in "working together at this point in time" then `pip upgrade` would work. > Also, distro package managers keep track of everything installed, while python ones (at least pip I'm 100% sure) don't. Are you sure you checked in the `*.dist-info` directories? There should be one per package, containing: a METADATA file, with all dependency versions, a RECORD file, with every installed file and their hash, and much more! see for yourself ;) > You could install a package which upgrades another one, and that breaks another that you had installed before and pip won't say a word. Let's agree to disagree right there: - in your point of view: this is a problem in pip - in my point of view: this is a maintenance problem in the python packages themselves, caused by the general practice of pinning
  - gjulianm 5y ago
    > Again, if all python package were up to date as in "working together at this point in time" then `pip upgrade` would work. That is impossible, it will never happen. Packages will have different maintenance cycles, some will get deprecated, others abandoned... You can't base your upgrade policy on an impossible situation. > Are you sure you checked in the `*.dist-info` directories? There should be one per package, containing: a METADATA file, with all dependency versions, a RECORD file, with every installed file and their hash, and much more! see for yourself ;) I know, but pip doesn't track all of those all the time. An example that has happened to me multiple times: install package X that depends on Y <= 1.0. Good, pip installs the proper version. Now, on another command, install package Z that depends on Y >= 2.0. Pip will install Y >= 2.0 and won't care that package X is now broken. > - in my point of view: this is a maintenance problem in the python packages themselves, caused by the general practice of pinning Regardless on your views on pinning, it's a problem in pip. A version conflict should be reported as an installation failure, not allow you to continue. And again, version restrictions will always be there. The "live at master" philosophy only works for small groups of similar output capacity. It won't work for an ecosystem as wide as Python. Even without version pinning, you'll still have packages breaking because another one was updated. Sometimes it will be necessary, such as for example a package dropping support for a feature that another one needs.
    - 1337shadow 5y ago
      > That is impossible, it will never happen. Packages will have different maintenance cycles, some will get deprecated, others abandoned... You can't base your upgrade policy on an impossible situation. You realize that if that was "impossible" and "never happening", then absolutely no Python environment would be working ever? > A version conflict should be reported as an installation failure, not allow you to continue. Please don't make this mandatory. > Pip will install Y >= 2.0 and won't care that package X is now broken. Fine, I'll just quickly fix X and open a pull request, like I probably did a hundred times, then eventually if necessary deploy my fork with the fix meanwhile they do their maintenance release. Should we not take the responsibility of the dependencies we use and contribute back?? > The "live at master" philosophy only works for small groups of similar output capacity. It won't work for an ecosystem as wide as Python. I don't understand why, but I'm talking about "live at latest release", not "at master". > Sometimes it will be necessary, such as for example a package dropping support for a feature that another one needs. Then the package can just paste the code of the feature in their own, until a new lib does it, I remember having to do that twice in 20 years (except I didn't just "paste" it, but implemented a much smaller version). Overall, it seems my approach produces versions of my software and software that I depend on that are compatible with all versions because you can always use an earlier version if you really want to deploy on an old python or whatnot, whereas you approach leads to broken packages, tech debt, and blaming the package manager.

gjulianm 5y ago

> However, installing every dependency in the same environment is also what distro package managers do, I don't see that as a recipe for disaster, Distro packages are done in a way where it's hard to get conflicts. I haven't found an instance where python3-X and python3-Y can't be installed because one requires python3-Z v1.2 and the other python3-Z v2.1. With Python packages, that happens way more often. Also, distro package managers keep track of everything installed, while python ones (at least pip I'm 100% sure) don't. You could install a package which upgrades another one, and that breaks another that you had installed before and pip won't say a word.

1337shadow 5y ago
> I haven't found an instance where python3-X and python3-Y can't be installed because one requires python3-Z v1.2 and the other python3-Z v2.1. With Python packages, that happens way more often. Exactly, because the packages were created/updated at a point in time were they were compatible: a distro ships python 3.x with packages of python modules that are compatible with python 3.x. Now if you as a user want to use a python package that works with python 3.y, you either have to wait, or install python 3.y, or use a container of python 3.y. Again, if all python package were up to date as in "working together at this point in time" then `pip upgrade` would work. > Also, distro package managers keep track of everything installed, while python ones (at least pip I'm 100% sure) don't. Are you sure you checked in the `*.dist-info` directories? There should be one per package, containing: a METADATA file, with all dependency versions, a RECORD file, with every installed file and their hash, and much more! see for yourself ;) > You could install a package which upgrades another one, and that breaks another that you had installed before and pip won't say a word. Let's agree to disagree right there: - in your point of view: this is a problem in pip - in my point of view: this is a maintenance problem in the python packages themselves, caused by the general practice of pinning
- gjulianm 5y ago
  > Again, if all python package were up to date as in "working together at this point in time" then `pip upgrade` would work. That is impossible, it will never happen. Packages will have different maintenance cycles, some will get deprecated, others abandoned... You can't base your upgrade policy on an impossible situation. > Are you sure you checked in the `*.dist-info` directories? There should be one per package, containing: a METADATA file, with all dependency versions, a RECORD file, with every installed file and their hash, and much more! see for yourself ;) I know, but pip doesn't track all of those all the time. An example that has happened to me multiple times: install package X that depends on Y <= 1.0. Good, pip installs the proper version. Now, on another command, install package Z that depends on Y >= 2.0. Pip will install Y >= 2.0 and won't care that package X is now broken. > - in my point of view: this is a maintenance problem in the python packages themselves, caused by the general practice of pinning Regardless on your views on pinning, it's a problem in pip. A version conflict should be reported as an installation failure, not allow you to continue. And again, version restrictions will always be there. The "live at master" philosophy only works for small groups of similar output capacity. It won't work for an ecosystem as wide as Python. Even without version pinning, you'll still have packages breaking because another one was updated. Sometimes it will be necessary, such as for example a package dropping support for a feature that another one needs.
  - 1337shadow 5y ago
    > That is impossible, it will never happen. Packages will have different maintenance cycles, some will get deprecated, others abandoned... You can't base your upgrade policy on an impossible situation. You realize that if that was "impossible" and "never happening", then absolutely no Python environment would be working ever? > A version conflict should be reported as an installation failure, not allow you to continue. Please don't make this mandatory. > Pip will install Y >= 2.0 and won't care that package X is now broken. Fine, I'll just quickly fix X and open a pull request, like I probably did a hundred times, then eventually if necessary deploy my fork with the fix meanwhile they do their maintenance release. Should we not take the responsibility of the dependencies we use and contribute back?? > The "live at master" philosophy only works for small groups of similar output capacity. It won't work for an ecosystem as wide as Python. I don't understand why, but I'm talking about "live at latest release", not "at master". > Sometimes it will be necessary, such as for example a package dropping support for a feature that another one needs. Then the package can just paste the code of the feature in their own, until a new lib does it, I remember having to do that twice in 20 years (except I didn't just "paste" it, but implemented a much smaller version). Overall, it seems my approach produces versions of my software and software that I depend on that are compatible with all versions because you can always use an earlier version if you really want to deploy on an old python or whatnot, whereas you approach leads to broken packages, tech debt, and blaming the package manager.