Why does everything related to versioning and packaging have to be so difficult with Python? I never understood that.
As an example, any time Homebrew ships a new update I run “pipx reinstall-all” and, for local projects, I let pipenv / poetry rebuild the virtualenv the next time I use it. This is automated and takes far less of my time than, say, managing dependency updates.
So, giving up (and re-installing everything from scratch or rebuilding virtualenvs, using several third party tools (pipx on top of pip, pipenv and/or poetry in lieu/in place of virtualenv) is your argument to how "it's not complicated" and people merely "arbitrarily complicate their personal workflows"?
Oh, the irony!
As to why there are two tools, it's because they have separate goals: pipx provides a robust way to manage global installs of Python utilities in per-tool virtualenvs while tools like poetry or pipenv are aimed at projects you're developing and handle things like automating the process of installing updates & updating the corresponding metadata files so you can ship clean updates. All of them use virtualenvs and pip underneath — it's just a modern workflow.
The key part is recognizing that the problem comes from trying to fight updates: software changes and accepting that means moving to a workflow which automates that rather than spending time trying to freeze everything in amber. Learning to use a tool every decade or so is a LOT less time consuming than doing this by hand. The average poster in this thread has already spent more time on this topic than my projects have needed for the mechanics of installing Python packages in any given year.
That we can automate our way out of a mess doesn't mean there is a mess.
Even more so if the automation involves extra inconvenience (like, from writing the automation to waiting to rebuild), which with a different design in the Python packaging wouldn't be needed.
>The key part is recognizing that the problem comes from trying to fight updates: software changes and accepting that means moving to a workflow which automates that rather than spending time trying to freeze everything in amber.
I can find and install updates just fine in other package managers for other languages, without messing my setup.
I can also move my whole environment to any path I like (with just copying).
> I can find and install updates just fine in other package managers for other languages, without messing my setup.
Just like Python, in other words? (remember, this thread is not about installing package updates)
> I can also move my whole environment to any path I like (with just copying).
The problem we're talking about here is what happens when you get a new build of the language itself. This is also true of most other dynamic languages unless you manage to avoid using any sort of native code linked against the language runtime. A compiled language which produces a static binary won't need that, of course, but that doesn't avoid the need to periodically recompile to stay current with dependencies and language changes. In all of these cases, automation makes the process fast and easy.
No, for very specific reasons. Historical cruft, too many competing tools (from pip to conda, and from venv to poetry, not to mention setuptools), conceptual garbage like wheels, pths, etc., non-movable virtual environments, and so on.
>The problem we're talking about here is what happens when you get a new build of the language itself. This is also true of most other dynamic languages unless you manage to avoid using any sort of native code linked against the language runtime.
And yet node handles this much more elegantly (with C++/gyp modules). And minor releases should absolutely no need this.
People are trying to fix it, and their are some great packages out there that make it easier. Pyenv, Poetry, this asdf tool the fine article mentions, all seem like good solutions.
So? You can still create nice tools for it, even decades after a language has been created...