undefined | Better HN

0 pointscoldtea5y ago0 comments

>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!

0 comments

3 comments · 1 top-level

acdha5y ago· 2 in thread

The key part which you missed is that everything is automated, always installed in an isolated virtual environment, the package are automatically tracked and updated, and the tools which make this happen are installed from Homebrew and update at the same time.

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.

coldteaOP5y ago

>The key part which you missed is that everything is automated, always installed in an isolated virtual environment, the package are automatically tracked and updated, and the tools which make this happen are installed from Homebrew and update at the same time.

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).

acdha5y ago

Your position seems to be that Python packaging is a mess for non-specific reasons but also that nobody is allowed to write tools to improve usability. Think about pip – that wasn't the first tool to do that job but it (gasp) automated several things which didn't have great solutions. Virtualenv has the same story. This will be no different.

> 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.

1 more reply

j / k navigate · click thread line to collapse