[HN Gopher] My User Experience Porting Off Setup.py
___________________________________________________________________
My User Experience Porting Off Setup.py
Author : markdog12
Score : 25 points
Date : 2023-10-30 10:51 UTC (12 hours ago)
(HTM) web link (gregoryszorc.com)
(TXT) w3m dump (gregoryszorc.com)
| stop50 wrote:
| Its more funny to migrate the old setup.py process to the
| pyproject.toml and an rpm specfile. with an setup.py you can say
| something like "python3 setup.py install -root=$builddir"
| Taikonerd wrote:
| Packages have always been Python's Achilles heel. Python's
| philosophy for _code_ is, "there should be one, and preferably
| only one, obvious way to do it." But for _packaging systems_ ,
| their philosophy is more like Perl: "there's more than one way to
| do it (and all of them have their own pitfalls)."
|
| I don't understand why the Python leadership hasn't shown
| stronger... leadership... in which tools they recommend.
| MrJohz wrote:
| My impression is that there's lots of different niches that
| have developed, each with their own needs, and trying to unify
| them is a mess.
|
| If you're putting something like a web app or something else
| that will be bundled and distributed as a unit, then you're
| probably best off with something like Poetry, PDM, or pip-tools
| - you have a lock file for deterministic dependencies, most of
| your dependencies will be pure python wheels, and you only
| really need to test things once. On the other hand, if you're
| developing a library, you'll need to test against multiple
| versions of Python, and ideally multiple versions of some of
| your larger dependencies, to ensure that your library will work
| for as many users as possible. You'll also need to be able to
| build and package wheels. Alternatively, you're working in data
| science, and your main concern is probably making sure you can
| install the packages you need in the environments you're going
| to use them - specifically, so that they work with the GPUs and
| other hardware you have available. And there's still the group
| of people writing mainly scripts for server maintenance or
| other tasks, who want to be able to easily install dependencies
| and keep those dependencies up to date for security reasons,
| with the minimum number of breaking changes.
|
| Right now, there are different tools, packaging systems, etc
| catering to each of these groups, and so building the One Ring
| of Python package management is going to involve (a) solving
| all of these problems, and (b) convincing all these groups of
| people that your general solution is better than their niche-
| specific solution. That's certainly not easy, I don't even know
| if it's all that possible.
|
| I do think that working from the ground up (i.e building the
| individual components like the package metadata file, or the
| pypackages folder experiment) seems to be working well, in that
| tools seem to be coalescing around these options and finding
| the best ways to use them, which is all work that might
| hopefully feed into new official tooling. But we'll see.
| tracnar wrote:
| It seems to stem from the Python packaging story being driven
| by PyPA, rather than the Python foundation, which appears
| reluctant to pick a packaging solution and ship it with
| CPython. setuptools was kind of an in-between, it was included
| in CPython but in many cases you have to update it or add
| plugins...
___________________________________________________________________
(page generated 2023-10-30 23:02 UTC)