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

171–180 of 479 posts

Re: PYX: The next step in Python packaging

#171

Post by jsmeaton »

Astral folks that are around - there seems to be a bit of confusion in the product page that the blog post makes a little more clear.

> The next step in Python packaging

The headline is the confusing bit I think - "oh no, another tool already?"

IMO you should lean into stating this is going to be a paid product (answering how you plan to make money and become sustainable), and highlight that this will help solve private packaging problems.

I'm excited by this announcement by the way. Setting up scalable private python registries is a huge pain. Looking forward to it!

Re: PYX: The next step in Python packaging

#172

Post by semiquaver »

nixpulvis wrote: post #169

Can I ask a dumb question. Why does Ruby (for example) not have this problem, but python still can't ship a standard solution which isn't constantly changing and rolled up in some corporate offering?

Before you answer that you have to answer what problem this is solving that PyPI doesn’t already address. uv works great against “legacy” package indexes so I’m not really clear why it’s needed other than to introduce lock-in to a for-profit facility.

Re: PYX: The next step in Python packaging

#173

Post by zzzeek »

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.

sorry, I guess you're new here? Here, try this Kool Aid. I think it will help you fit in. oh don't mind that "MongoDB" logo on the glass that's old

Re: PYX: The next step in Python packaging

#174

Post by zanie »

jsmeaton wrote: post #171

Astral folks that are around - there seems to be a bit of confusion in the product page that the blog post makes a little more clear. > The next step in Python packaging The headline is the confusing bit I think - "oh no, another tool already?" IMO you should lean into stating this is going to be a paid product (answering how you plan to make money and become sustainable), and highlight that this will help solve priv…

Thanks for the feedback!

Re: PYX: The next step in Python packaging

#175

Post by NegativeLatency »

tempest_ wrote: post #155
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.

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've been heartened by the progress that opentofu has made, so I think if it gets enough momentum it could survive the inevitable money grab

Re: PYX: The next step in Python packaging

#176

Post by anitil »

tempest_ wrote: post #155
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.

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

Re: PYX: The next step in Python packaging

#177

Post by kccqzy »

nodesocket wrote: post #77
fph wrote: post #56

I lost track of how many different ways to install a Python library there are at the moment.

Much better than the Node a handful of years back. Everybody used NPM, everybody switched to Yarn, everybody switched back to NPM.

It's a good thing that a newcomer came and showed the world some new concepts which ended up being adopted by the old tool. In the Haskell world, everybody used cabal, everybody switched to stack, and then everybody switched back to cabal once it got its new-build commands ready.

Re: PYX: The next step in Python packaging

#178

Post by JonChesterfield »

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.

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 much the same experience. Also the vestiges of 2 vs 3 are still kicking around in the forms of refusing to find a package based on the number being present or absent.

Whatever c++headerparser might be, I'm left very sure that hacking python out of the build tree and leaving it on the trash heap of history is the proper thing to do.

Re: PYX: The next step in Python packaging

#179

Post by LtWorf »

zahlman wrote: post #142
LtWorf wrote: post #116

Earlier quoted context omitted.

I've been limiting myself to whatever is available on debian and it's been fine for me since several years. I don't understand why people who don't do weird AI stuff would use any of that instead of sticking to distribution packages and having the occasional 1 or 2 external modules that aren't packaged.

Because making external modules cooperate with the system environment is awkward at best (and explicitly safeguarded against since 3.11, since it can cause serious problems otherwise even with "user" installs), and installing the distro's packages in a separate environment is not supported as far as I can tell. And because the system environment is often deliberately crippled; it may not even include the entire stand…

> the system environment is often deliberately crippled; it may not even include the entire standard library.

well getting a good system is step 1

Re: PYX: The next step in Python packaging

#180

Post by int_19h »

nickserv wrote: post #60
nurettin wrote: post #53

Earlier quoted context omitted.

Have you tried JRuby? It might be a bit too large for your droplet, but it has the java versions of most gems and you can produce cross-platform jars using warbler.

The speed of Ruby with the memory management of Java, what's not to love? Also, now you have two problems.

Java has quite possibly the best production GC of all the VMs out there.
Post reply on HN