9 ms·

To me the natural choice would be pip which, as OP points out, has the advantage of shipping with Python by default. We could remedy the shortcomings of pip by

To me the natural choice would be pip which, as OP points out, has the advantage of shipping with Python by default. We could remedy the shortcomings of pip by incorporating the most successful features from the N alternatives that exist today. The npm/yarn fork that formed in 2016 is the closest analogy I can think of. My impression is that npm improved on its biggest weaknesses (e.g. a lock file) and has remained the default choice in that ecosystem. I suspect the same would happen with pip if it too made significant improvements.

lmm 4y ago
Shipping with python is a disadvantage; any real workflow tool needs to be able to manage multiple python installations, and if you try to use a part of the python installation to do that you've got a circular dependency problem. Plus the whole "where modules go to die" thing.
- solarkraft 4y ago
  Does anything speak against flipping the relationship? i.e. using pip (or something else) as the standard way to install Python.
  - cdogl 4y ago
    pip is a python program.
  - qbasic_forever 4y ago
    You might want to look at micromamba as a separate tool that can install python itself, libraries, etc. with zero dependency on a python being installed. It's a very fast tool written in C++ so it's easy to install and use almost anywhere. It uses the conda ecosystem of packages.
- LtWorf 4y ago
  If you have multiple versions of python installed you can just do python3.9 -m pip python3.10 -m pip The standard library is the reason why python is popular to begin with.
  - Hackbraten 4y ago
    To me, that’d be a UX nightmare. Even if I tried to, I’m not going to memorize which of my 20 checked-out Python projects are requiring which Python invocation. IMHO it’s absolutely the toolchain’s job to manage that for me. I’d never adopt a toolchain that wouldn’t.
    - LtWorf 4y ago
      You do know that python is backwards compatible right? You can just use 3.11 with everything.
      - Hackbraten 4y ago
        If my project is a library that needs to support e.g. 3.8 through 3.11, then I’m not going to use 3.11 for my development environment. The same goes if my project depends on a library or framework that doesn’t support 3.11.
      - lmm 4y ago
        Traditionally it wasn't, and even a "minor" upgrade was a significant undertaking for a large project. Maybe that's changed.
        mattbillenstein 4y ago
        Maybe in the 2.4 -> 2.7 transitions - Python3 after about 3.6 is pretty good, you might see some minor package breakage if you're running the very latest version, but that's fairly rare. Generally speaking, if you're on a modern OS - like recent Ubuntu LTS or MacOS you're getting 3.8 -> 3.10 and compatibility is very good in these releases.
        acdha 4y ago
        When exactly are you defining as “traditional”? The Python point releases have generally been painless for a long time. There was a little friction in the early 2-3 era before they made it easier to write code which worked on both without translation but in general it’s been at least a decade since I’ve cared about this except for one time where a couple of libraries depended on a private API which changed in Python 2.7.9, and that was back in 2014. https://bugs.python.org/issue22438 https://bugs.python.org/issue22438
Aeolun 4y ago
To some extend. NPM is still (even after all the improvements) the weakest of the package managers. There’s no doubt it’s the default though.
- deleted 4y ago
  [deleted]
AlphaSite 4y ago
Even if pip was a little better I still wouldn’t use it, because Poetry solves the problem so well you’d need to pull it out of my cold hands. It solves not only the install package problem, but locking, venvs, project structure and packaging in a well integrated solution with a fantastic UX. If poetry (or similar) were renamed to Pip and it were to be included in the stdlib id obviously switch. It doesn’t solve the single static binary problem or docs problems, but it’s much much closer.
- 411111111111111 4y ago
  Everytime you install a package through poetry, you're also running pip code. You didn't even understand the point they made: the need for Pipenv and poetry would pretty much go away if pip added support for a proper lockfile and venvs. And that's the only correct choices as pip is already pythons package manager.
  - bombolo 4y ago
    What's the problem with first doing the venv thing and then running pip?
    - numbsafari 4y ago
      Any multi step process is guaranteed to produce random assortments of workflow tools to manage those steps which will seek to replace the original process as the one true process. If there two steps, one part of the community will insist they belong in: a makefile, bash script, python script, lambda network service, bazel, pants, scons, terraform, ansible, npm …
      - bombolo 4y ago
        So we should have 1 single shell command to do literally everything?
        411111111111111 4y ago

lmm 4y ago

Shipping with python is a disadvantage; any real workflow tool needs to be able to manage multiple python installations, and if you try to use a part of the python installation to do that you've got a circular dependency problem. Plus the whole "where modules go to die" thing.

solarkraft 4y ago
Does anything speak against flipping the relationship? i.e. using pip (or something else) as the standard way to install Python.
- cdogl 4y ago
  pip is a python program.
- qbasic_forever 4y ago
  You might want to look at micromamba as a separate tool that can install python itself, libraries, etc. with zero dependency on a python being installed. It's a very fast tool written in C++ so it's easy to install and use almost anywhere. It uses the conda ecosystem of packages.
LtWorf 4y ago
If you have multiple versions of python installed you can just do python3.9 -m pip python3.10 -m pip The standard library is the reason why python is popular to begin with.
- Hackbraten 4y ago
  To me, that’d be a UX nightmare. Even if I tried to, I’m not going to memorize which of my 20 checked-out Python projects are requiring which Python invocation. IMHO it’s absolutely the toolchain’s job to manage that for me. I’d never adopt a toolchain that wouldn’t.
  - LtWorf 4y ago
    You do know that python is backwards compatible right? You can just use 3.11 with everything.
    - Hackbraten 4y ago
      If my project is a library that needs to support e.g. 3.8 through 3.11, then I’m not going to use 3.11 for my development environment. The same goes if my project depends on a library or framework that doesn’t support 3.11.
    - lmm 4y ago
      Traditionally it wasn't, and even a "minor" upgrade was a significant undertaking for a large project. Maybe that's changed.
      - mattbillenstein 4y ago
        Maybe in the 2.4 -> 2.7 transitions - Python3 after about 3.6 is pretty good, you might see some minor package breakage if you're running the very latest version, but that's fairly rare. Generally speaking, if you're on a modern OS - like recent Ubuntu LTS or MacOS you're getting 3.8 -> 3.10 and compatibility is very good in these releases.
      - acdha 4y ago
        When exactly are you defining as “traditional”? The Python point releases have generally been painless for a long time. There was a little friction in the early 2-3 era before they made it easier to write code which worked on both without translation but in general it’s been at least a decade since I’ve cared about this except for one time where a couple of libraries depended on a private API which changed in Python 2.7.9, and that was back in 2014. https://bugs.python.org/issue22438 https://bugs.python.org/issue22438

Aeolun 4y ago

To some extend. NPM is still (even after all the improvements) the weakest of the package managers. There’s no doubt it’s the default though.

deleted 4y ago
[deleted]

AlphaSite 4y ago

Even if pip was a little better I still wouldn’t use it, because Poetry solves the problem so well you’d need to pull it out of my cold hands. It solves not only the install package problem, but locking, venvs, project structure and packaging in a well integrated solution with a fantastic UX. If poetry (or similar) were renamed to Pip and it were to be included in the stdlib id obviously switch. It doesn’t solve the single static binary problem or docs problems, but it’s much much closer.

411111111111111 4y ago
Everytime you install a package through poetry, you're also running pip code. You didn't even understand the point they made: the need for Pipenv and poetry would pretty much go away if pip added support for a proper lockfile and venvs. And that's the only correct choices as pip is already pythons package manager.
- bombolo 4y ago
  What's the problem with first doing the venv thing and then running pip?
  - numbsafari 4y ago
    Any multi step process is guaranteed to produce random assortments of workflow tools to manage those steps which will seek to replace the original process as the one true process. If there two steps, one part of the community will insist they belong in: a makefile, bash script, python script, lambda network service, bazel, pants, scons, terraform, ansible, npm …
    - bombolo 4y ago
      So we should have 1 single shell command to do literally everything?
      - 411111111111111 4y ago