PYX: The next step in Python packaging • Hacker News Board

Re: PYX: The next step in Python packaging

#41

Post by zemo » Wed, Aug 13, 2025, 8:12 PM UTC

woodruffw wrote: post #19

monster_truck wrote: post #10

I've been burned too many times by embracing open source products like this. We've been fed promises like these before. They will inevitably get acquired. Years of documentation, issues, and pull requests will be deleted with little-to-no notice. An exclusively commercial replacement will materialize from the new company that is inexplicably missing the features you relied on in the first place.

For what it's worth, I understand this concern. However, I want to emphasize that pyx is intentionally distinct from Astral's tools. From the announcement post: > Beyond the product itself, pyx is also an instantiation of our strategy: our tools remain free, open source, and permissively licensed — forever. Nothing changes there. Instead, we'll offer paid, hosted services that represent the "natural next thing you ne…

> Basically, we're hoping to address this concern by building a separate sustainable commercial product rather than monetizing our open source tools.

jfrog artifactory suddenly very scared for its safety

Re: PYX: The next step in Python packaging

#42

Post by notatallshaw » Wed, Aug 13, 2025, 8:13 PM UTC

zanie wrote: post #25

notatallshaw wrote: post #7

Earlier quoted context omitted.

Given Astral's heavy involvement in the wheelnext project I suspect this index is an early adopter of Wheel Variants which are an attempt to solve the problems of CUDA (and that entire class of problems not just CUDA specifically) in a more automated way than even conda: https://wheelnext.dev/proposals/pepxxx_wheel_variant_support...

It's actually not powered by Wheel Variants right now, though we are generally early adopters of the initiative :)

Well it was just a guess, "GPU-aware" is a bit mysterious to those of us on the outside ;).

Re: PYX: The next step in Python packaging

#43

Post by formerly_proven » Wed, Aug 13, 2025, 8:14 PM UTC

dakiol wrote: post #39

I'm brushing up with Python for a new job, and boy what a ride. Not because of the language itself but the tooling around packages. I'm coming from Go and TS/JS and while these two ecosystems have their own pros and cons, at least they are more or less straightforward to get onboarded (there are 1 or 2 tools you need to know about). In Python there are dozens of tools/concepts related to packaging: pip, easy_install,…

> Don't understand how a private company like Astral is leading here. Why is that hard for the Python community to come up with a single tool to rule them all? (I know https://xkcd.com/927/). Like, you could even copy what Go or Node are doing, and make it Python-aware; no shame on that. Instead we have these who-knows-how-long-they-will-last tools every now and then.

Python packaging is (largely) solving problems that Go and Node packaging are not even trying to address.

Re: PYX: The next step in Python packaging

#44

Post by Muromec » Wed, Aug 13, 2025, 8:14 PM UTC

krupan wrote: post #35

o11c wrote: post #28

Earlier quoted context omitted.

The entire reason people choose "permissive licenses" is so that it won't last forever. At best, the community can fork the old version without any future features. Only viral licenses are forever.

I think you are making a good point, but please don't use the old Steve Baller FUD term, "viral." Copyleft is a better term

The word "left" is now very charged too, maybe even more than "viral".

Re: PYX: The next step in Python packaging

#45

Post by giancarlostoro » Wed, Aug 13, 2025, 8:16 PM UTC

m_kos wrote: post #40

> Why is it so hard to install PyTorch, or CUDA, or libraries like FlashAttention or DeepSpeed that build against PyTorch and CUDA? This is so true! On Windows (and WSL) it is also exacerbated by some packages requiring the use of compilers bundled with outdated Visual Studio versions, some of which are only available by manually crafting download paths. I can't wait for a better dev experience.

Stuff like that led me fully away from Ruby (due to Rails), which is a shame, I see videos of people chugging along with Ruby and loving it, and it looks like a fun language, but when the only way I can get a dev environment setup for Rails is using DigitalOcean droplets, I've lost all interest. It would always fail at compiling something for Rails. I would have loved to partake in the Rails hype back in 2012, but over the years the install / setup process was always a nightmare.

I went with Python because I never had this issue. Now with any AI / CUDA stuff its a bit of a nightmare to the point where you use someone's setup shell script instead of trying to use pip at all.

Re: PYX: The next step in Python packaging

#46

Post by notatallshaw » Wed, Aug 13, 2025, 8:19 PM UTC

dakiol wrote: post #39

I'm brushing up with Python for a new job, and boy what a ride. Not because of the language itself but the tooling around packages. I'm coming from Go and TS/JS and while these two ecosystems have their own pros and cons, at least they are more or less straightforward to get onboarded (there are 1 or 2 tools you need to know about). In Python there are dozens of tools/concepts related to packaging: pip, easy_install,…

> easy_install

I don't know what guides you're reading but I haven't touched easy_install in at least a decade. It's successor, pip, had effectively replaced all use cases for it by around 2010.

Re: PYX: The next step in Python packaging

#47

Post by Spivak » Wed, Aug 13, 2025, 8:20 PM UTC

formerly_proven wrote: post #43

dakiol wrote: post #39

I'm brushing up with Python for a new job, and boy what a ride. Not because of the language itself but the tooling around packages. I'm coming from Go and TS/JS and while these two ecosystems have their own pros and cons, at least they are more or less straightforward to get onboarded (there are 1 or 2 tools you need to know about). In Python there are dozens of tools/concepts related to packaging: pip, easy_install,…

> Don't understand how a private company like Astral is leading here. Why is that hard for the Python community to come up with a single tool to rule them all? (I know https://xkcd.com/927/ ). Like, you could even copy what Go or Node are doing, and make it Python-aware; no shame on that. Instead we have these who-knows-how-long-they-will-last tools every now and then. Python packaging is (largely) solving problems t…

Specifically simultaneous distribution of precompiled binaries for many different OS and hardware configurations and built-on-demand source distribution of non-Python software to be used as dependencies with as little (ideally none) host setup by the user all installable under a single name/version everywhere.

imagine a world without: failed to build native gem extension

Re: PYX: The next step in Python packaging

#48

Post by lenerdenator » Wed, Aug 13, 2025, 8:22 PM UTC

kinow wrote: post #18

ctoth wrote: post #8

As I said a couple weeks ago, they're gonna have to cash out at some point. The move won't be around Uv -- it'll be a protected private PyPi or something. https://news.ycombinator.com/item?id=44712558 Now what do we have here?

I haven't adopted uv yet watching to see what will be their move. We recently had to review our use of Anaconda tools due to their changes, then review Qt changes in license. Not looking forward to another license ordeal.

Fortunately for a lot of what uv does, one can simply switch to something else like Poetry. Not exactly a zero-code lift but if you use pyproject.toml, there are other tools.

Of course if you are on one of the edge cases of something only uv does, well... that's more of an issue.

Re: PYX: The next step in Python packaging

#49

Post by asa400 » Wed, Aug 13, 2025, 8:24 PM UTC

formerly_proven wrote: post #43

dakiol wrote: post #39

I'm brushing up with Python for a new job, and boy what a ride. Not because of the language itself but the tooling around packages. I'm coming from Go and TS/JS and while these two ecosystems have their own pros and cons, at least they are more or less straightforward to get onboarded (there are 1 or 2 tools you need to know about). In Python there are dozens of tools/concepts related to packaging: pip, easy_install,…

> Don't understand how a private company like Astral is leading here. Why is that hard for the Python community to come up with a single tool to rule them all? (I know https://xkcd.com/927/ ). Like, you could even copy what Go or Node are doing, and make it Python-aware; no shame on that. Instead we have these who-knows-how-long-they-will-last tools every now and then. Python packaging is (largely) solving problems t…

As someone outside those communities, could you elaborate?

Re: PYX: The next step in Python packaging

#50

Post by woodruffw » Wed, Aug 13, 2025, 8:25 PM UTC

notpushkin wrote: post #38

woodruffw wrote: post #32

Earlier quoted context omitted.

I don't think this is true -- a license's virality doesn't mean that its copyright holders can't switch a future version to a proprietary license; past grants don't imply grants to future work under any open source license.

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 picture here is that Astral wants to build services as a product, rather than compromising the open source nature of its tools. That's why the announcement tries to cleanly differentiate between the two.