Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PYX: The next step in Python packaging

astral.sh

Post reply on HN
Print view View original

201–210 of 479 posts

Re: PYX: The next step in Python packaging

#201

Post by mixmastamyk »

zahlman wrote: post #117
mixmastamyk wrote: post #99

Earlier quoted context omitted.

Indeed, they broke a few features in the last few years and made the excuse "we can't support them, we're volunteers." Well, how about stop breaking things that worked for a decade? That would take less effort. They had time to force "--break-system-packages" on us though, something no one asked for.

> how about stop breaking things that worked for a decade? They aren't doing this. > They had time to force "--break-system-packages" on us though, something no one asked for. The maintainers of several Linux distros asked for it very explicitly, and cooperated to design the feature. The rationale is extensively documented in the proposal ( https://peps.python.org/pep-0668/ ). This is especially important for distros…

Oh really?

- https://github.com/pypa/packaging/issues/774

- https://github.com/pypa/setuptools/issues/3548

- https://github.com/pypa/pip/issues/7953

I relied on those for a decade, maybe two.

> something no one asked for

Was being a facetious, sure someone asked for it, but it was pretty dumb. This has never "corrupted" anything, is rare (not happened to me in last 15 years), and simply fixed when knowledgeable.

Not everyone can simply fix it, so a better solution would be to isolate the system python, allow more than one installed, etc. Distros already do this to some extent.

Re: PYX: The next step in Python packaging

#202

Post by pxc »

woodruffw wrote: post #50
notpushkin wrote: post #38

Earlier quoted context omitted.

Correct; however, without a CLA and assuming there are outside contributors, relicensing the existing code would be mildly painful, if not downright impossible.

You're saying that would be more painful in a viral license setting, right? If so I agree, although I think there's a pretty long track record of financially incentivized companies being willing to take that pain. MongoDB's AGPL transition comes to mind. But, to refocus on the case at hand: Astral's tools don't require contributors to sign a CLA. I understand (and am sympathetic) to the suspicion here, but the bigger…

> I think there's a pretty long track record of financially incentivized companies being willing to take that pain. MongoDB's AGPL transition comes to mind.

MongoDB had a CLA from the start, didn't it?

> Astral's tools don't require contributors to sign a CLA.

That's a pretty vital difference!

Re: PYX: The next step in Python packaging

#203

Post by kouteiheika »

russellbeattie wrote: post #184

What are the reasons that Python can't implement the same sort of module/packaging system as NodeJS? That seems to work well enough. Executing a Python script in the same directory as some sort of project.json file that contains all the complicated dependency details would be a pretty good solution to me. But I'm probably missing a whole bunch of details. (Feel free to educate me). In general I really dislike the cur…

It can. That's what uv is. Put an '#!/usr/bin/env -S uv run python' shebang in your script, add a `pyproject.toml` with all of your deps, and you're done.

Re: PYX: The next step in Python packaging

#204

Post by bastawhiz »

runningmike wrote: post #103

All python packaging challenges are solved. Lesson learned is that there is not a single solution for all problems. getting more strings attached with VC funded companies and leaning on their infrastructure is a high risk for any FOSS community.

Well I started with pip because it's what I was told to use. But it was slow and had footguns. And then I started using virtualenv, but that only solved part of the problem. So I switched to conda, which sometimes worked but wrecked my shell profile and often leads to things mysteriously using the wrong version of a package. So someone told me to use pipenv, which was great until it was abandoned and picked up by someone who routinely broke the latest published version. So someone told me to use poetry, but it became unusably slow. So I switched back to pip with the built-in venv, but now I have the and problems I had before, with fewer features. So I switched to uv, because it actually worked. But the dependency I need is built and packaged differently for different operating systems and flavor of GPU, and now my coworkers can't get the project to install on their laptops.

I'm so glad all the Python packaging challenges are "solved"

Re: PYX: The next step in Python packaging

#205

Post by seriocomic »

bastawhiz wrote: post #204
runningmike wrote: post #103

All python packaging challenges are solved. Lesson learned is that there is not a single solution for all problems. getting more strings attached with VC funded companies and leaning on their infrastructure is a high risk for any FOSS community.

Well I started with pip because it's what I was told to use. But it was slow and had footguns. And then I started using virtualenv, but that only solved part of the problem. So I switched to conda, which sometimes worked but wrecked my shell profile and often leads to things mysteriously using the wrong version of a package. So someone told me to use pipenv, which was great until it was abandoned and picked up by som…

I've walked the same rocky path and have the bleeding feet to show for it! My problem is that now my packaging/environment mental model is so muddled I frequently mix up the commands...

Re: PYX: The next step in Python packaging

#206

Post by ghshephard »

nemomarx wrote: post #187
JonChesterfield wrote: post #178

Earlier quoted context omitted.

I've been dealing with python vs debian for the last three hours and am deeply angry with the ecosystem. Solved it is not. Debian decided you should use venv for everything. But when packages are installed in a venv, random cmake nonsense does not find them. There are apt-get level packages, some things find those, others do not. Names are not consistent. There's a thing called pipx which my console recommended for m…

from what I hear uv is the "solved" and venv by hand is the old way

uv is venv + insanely fast pip. I’ve used it every day for 5+ months and I still stare in amazement every time I use it. It’s probably the most joy I’ve ever gotten out of technology.

Re: PYX: The next step in Python packaging

#207

Post by nemosaltat »

anitil wrote: post #176
tempest_ wrote: post #155

Earlier quoted context omitted.

I share your concern but I have saved so much time with uv already that I figure ill ride it till the VC enshitification kills the host. Hopefully at the point the community is centralized enough to move in one direction.

I agree, now I just use uv and forget about it. It does use up a fair bit of disk, but disk is cheap and the bootstrapping time reduction makes working with python a pleasure again

Couldn’t agree more and the `uv run executable.sh` that contains a shebang, imports and then python is just magical.

Re: PYX: The next step in Python packaging

#208

Post by anon7000 »

chao- wrote: post #153
6thbit wrote: post #127

Earlier quoted context omitted.

Thanks that’s bit less cryptic than the linked page. Still don’t get how they are solving what they claim to solve.

I suspect that, in order to succeed, they will need to build something that is isomorphic to Nix.

They already built uv, which works extremely well for that

Re: PYX: The next step in Python packaging

#209

Post by anothernewdude »

bastawhiz wrote: post #204
runningmike wrote: post #103

All python packaging challenges are solved. Lesson learned is that there is not a single solution for all problems. getting more strings attached with VC funded companies and leaning on their infrastructure is a high risk for any FOSS community.

Well I started with pip because it's what I was told to use. But it was slow and had footguns. And then I started using virtualenv, but that only solved part of the problem. So I switched to conda, which sometimes worked but wrecked my shell profile and often leads to things mysteriously using the wrong version of a package. So someone told me to use pipenv, which was great until it was abandoned and picked up by som…

I felt like python packaging was more or less fine, right up until pip started to warn me that I couldn't globally install packages anymore. So I need to make a billion venvs to install the same ml, plotting libraries and dependencies, that I don't want in a requirements.txt for the project.

I just want packaging to fuck off and leave me alone. Changes here are always bad, because they're changes.

Re: PYX: The next step in Python packaging

#210

Post by dwattttt »

kouteiheika wrote: post #203
russellbeattie wrote: post #184

What are the reasons that Python can't implement the same sort of module/packaging system as NodeJS? That seems to work well enough. Executing a Python script in the same directory as some sort of project.json file that contains all the complicated dependency details would be a pretty good solution to me. But I'm probably missing a whole bunch of details. (Feel free to educate me). In general I really dislike the cur…

It can. That's what uv is. Put an '#!/usr/bin/env -S uv run python' shebang in your script, add a `pyproject.toml` with all of your deps, and you're done.

> add a `pyproject.toml` with all of your deps

Or put your dependencies inline in the script (https://packaging.python.org/en/latest/specifications/inline...), and it's just a single file script again. But with dependency support

EDIT to clarify it was just the pyproject.toml that inline metadata could replace

Post reply on HN