4 ms·

In before 'Python dependency management isn't hard. You just use {newest Python flavor-of-the-year way} of doing {same thing that is standardized in other langu

• lanstin 2y ago
  "There should be one-- and preferably only one --obvious way to do it." It was originally not a bazaar but "batteries included" where the thing you wanted to do had an obvious best way of doing it. An extremely difficult property to maintain over the decades.
• thesuperbigfrog 2y ago
  So with Python dependency management 'there is more than one way to do it': pip, pipenv, poetry, conda, setuptools, hatch, micropipenv, PDM, pip-tools, egg, uv, ActiveState platform, homebrew, your operating system's package manager, and many others . . . Relevant xkcd: https://xkcd.com/1987/ https://xkcd.com/1987/
  • zahlman 2y ago
    Of the list you offer, only Poetry, Hatch, PDM and Uv actually do "Python dependency management" - in the sense of offering an update command to recalculate locked versions of dependencies, a wrapper to install or upgrade those dependencies, and a wrapper to keep track of which environment they'll be installed into. pipenv, micropipenv and pip-tools are utilities for creating records of dependencies, but don't actually "manage" those dependencies in the above sense. Your list also includes an installer (Pip), a build backend (Setuptools - although it has older deprecated use as something vaguely resembling a workflow tool similar to modern dependency managers), a long-deprecated file format (egg) which PyPI hasn't even accepted for a year and a half (https://packaging.python.org/en/latest/discussions/package-formats/ https://packaging.python.org/en/latest/discussions/package-f...), two alternative sources for Python itself (ActiveState and homebrew - and I doubt anyone has a good reason to use ActiveState any more), and two package management solutions that are orthogonal to the Python ecosystem (Conda - which was created to support Python, but its environments aren't particularly Python-centric - and Linux system package managers). Any system can be made to look complex by conflating its parts with other vaguely related but ultimately irrelevant objects.
    • pepa65 2y ago
      You seem to know a lot about it, but you're really just reinforcing the point.
      • zahlman 2y ago
        I don't see how. There aren't as many options as GP represents, because most of the things in the list are simply non sequitur.
    • thesuperbigfrog 2y ago
      What do you think is the best way to manage Python dependencies and why?
      • zahlman 2y ago
        My entire point is that there is no best way, because people have varying needs and preferences and aesthetic senses. In my opinion, the best state of the ecosystem involves having a single integrated tool for users (it creates venvs and installs libraries and applications to them, and runs applications in temporary venvs) plus multiple small Unix-philosophy tools for developers, to do the individual tasks they need done. There can be choices for each of these - especially for build backends (PEP 517 was designed specifically to enable competition there). In this world, people could still have all-in-one workflow tools - which mainly just integrate smaller pieces.
• zahlman 2y ago
  Nobody agrees on what the entire "dependency management" process entails. If they supported everyone's use case in a standard tool, many people would be unhappy with how certain things were done, and many more people would ignore a huge fraction of it. New workflow tools like Poetry, PDM, Hatch, uv etc. tend to do a lot of wheel reinvention, in large part because the foundational tools are flawed. In principle, you can do everything with single-purpose tools. The real essentials look like: * Pip to install packages * venv to create environments * `build` as a build frontend to create your own distributions * a build backend (generally specified by the package, and set up automatically by the frontend) to create sdists and wheels for distribution * `twine` to put sdists and wheels on PyPI The problems are: * Determining what to install is hard and people want another tool to do that, and track/update/lock/garbage-collect dependencies * Keeping track of what venvs you made, and which contains what, is apparently hard for some users; they want a tool to help make them, and use the right one when you run the code, and have an opinion about where to keep them * Pip has a lot of idiosyncrasies; its scope is both too wide in some places and too narrow in others, it's clunky to use (the UI has never had any real design behind it, and the "bootstrap Pip into each venv" model causes more problems), and it's way too eager to build sdists that won't end up getting installed (which apparently is hard to fix because of the internal structure of the code) * Setuptools, the default build backend, has a legacy of trying to be an entire workflow management tool, except targeting very old ideas of what that should entail; now it's an absurdly large pile of backwards-compatibility wrappers in order to keep supporting old-fashioned ways of doing things. And yet, it actually does very little in a modern project that uses it: directly calling `setup.py` is deprecated, and most of what you would pass to the `setup` call can be described in `pyproject.toml` instead; yet when you just properly use it as a build backend, it has to obtain a separate package (`wheel`) to actually build a wheel * Project metadata is atrocious, proximately a standardization issue, but ultimately because legacy `setup.py`-exclusive approaches are still supported