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

341–350 of 479 posts

Re: PYX: The next step in Python packaging

#341

Post by IshKebab »

halfcat wrote: post #190
mnazzaro wrote: post #139

Earlier quoted context omitted.

This is a valid concern, but astral just has an amazing track record. I was surprised to see the community here on HN responding so cautiously. Been developing in python for about a decade now- whenever astral does something I get excited!

> This is a valid concern, but astral just has an amazing track record. The issue is, track record is not relevant when the next investors take over.

I agree in principle, but in this case uv is open source and SO MUCH better than pip it would be insane not to use it on those grounds.

With uv the worst case is it goes closed source in a few years and we all switch to a fork.

With pip the best case is that maybe in 10 years they have improved it to fix all the issues that uv has already fixed, and you only spend 10 years using shitty software and putting up with endless bugs and paper cuts.

Re: PYX: The next step in Python packaging

#342

Post by IshKebab »

MoreQARespect wrote: post #128
snooniverse wrote: post #29

Earlier quoted context omitted.

Not sure what you're trying to get at here. Charlie Marsh has literally said this himself; see e.g. this post he made last September: > "An example of what this might look like (we may not do this, but it's helpful to have a concrete example of the strategy) would be something like an enterprise-focused private package registry." https://hachyderm.io/@charliermarsh/113103605702842937 Astral has been very transparent…

Astral doesn't really have a business model yet, it has potential business models. The issue is that there isn't a clean business model that will produce the kind of profits that will satisfy their VCs - not that there isn't any business model that will help support a business like theirs. Private package management would probably work fine if they hadn't taken VC money.

I would have agreed with you until I learned that Conda somehow makes $150m in revenue a year. They have fewer users than Astral too (or if not they will do very soon).

Re: PYX: The next step in Python packaging

#343

Post by dandellion »

abdullahkhalids wrote: post #123
woodruffw wrote: post #19

Earlier quoted context omitted.

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…

I believe that you are sincere and truthful in what you say. Unfortunately, the integrity of employees is no guard against the greed of investors. Maybe next year investors change the CEO and entire management and they start monetizing the open source tools. There is no way of knowing. But history tells us that there is a non-trivial chance of this happening.

Yes, at every company I have been with investors, sooner or later they make the calls, what the founders wanted never has much weight a few years in.

Re: PYX: The next step in Python packaging

#344

Post by IshKebab »

zanie wrote: post #174
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!

I would also put this list of issues that this fixes higher. It makes it more obvious what the point is. (And also a setuptools update literally broke our company CI last week so I was like "omg yes" at that point.)

Re: PYX: The next step in Python packaging

#345

Post by IshKebab »

aidenn0 wrote: post #284
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,…

I don't know; I was looking at TS tutorials the other day and there seemed to be at least half a dozen "bundlers" with different tutorails suggesting different ones to use. It took me a while to figure out I could just directly invoke "tsc" to generate javascript from typescript.

Yeah Typescript is maybe not the best example. Go, Rust and Zig get this right though. And Deno, which is based on Typescript.

Re: PYX: The next step in Python packaging

#346

Post by IshKebab »

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,…

I actually think the main problem is that they aren't even willing to admit that there is a problem. It's the classic "our program is great; if users have issues it's because they are using it wrong / didn't read the manual / are stupid".

Go and look up why you can't run scripts with `python3 foo.py` on Windows. It's like a one-line fix and they've come up with all sorts of naysaying reasons rather than just adding python3.exe (which Microsoft did years ago in their Python packages).

Re: PYX: The next step in Python packaging

#347

Post by biorach »

jillesvangurp wrote: post #309
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,…

> Why is that hard for the Python community to come up with a single tool to rule them all? Design by committee is hard. Especially building consensus around reconsidering what at this point should be considered bad design. Python has a few decades of that. It took decades for the to even consider starting the process of removing the GIL, which is a great example of "it's clearly broken but lets not fix it". Packagin…

> It took decades for the to even consider starting the process of removing the GIL,

This is not true. Discussions about removing the GIL have been ongoing for decades. There were some abortive attempts over the years but it is regarded as quite the technical challenge, and has implications for compatibility with code written in C.

> which is a great example of "it's clearly broken but lets not fix it".

That is not the attitude of the Python community.

Re: PYX: The next step in Python packaging

#348

Post by biorach »

Thrymr wrote: post #144
notatallshaw wrote: post #46

Earlier quoted context omitted.

> 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.

> I don't know what guides you're reading but I haven't touched easy_install in at least a decade. It is mentioned in the "Explanations and Discussions" section [0] of the linked Python Packaging guide. Old indeed, but can still be found at the top level of the current docs. [0] https://packaging.python.org/en/latest/#explanations-and-dis...

Yes, it is mentioned there, as being deprecated:

> easy_install, now deprecated, was released in 2004 as part of Setuptools.

Re: PYX: The next step in Python packaging

#349

Post by Epa095 »

pxc wrote: post #202
woodruffw wrote: post #50

Earlier quoted context omitted.

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!

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

> That's a pretty vital difference

Not really when the license is MIT/Apache. They can create a closed source fork and continue development there.

Re: PYX: The next step in Python packaging

#350

Post by cgravill »

pama wrote: post #235
nemomarx wrote: post #187

Earlier quoted context omitted.

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

These tools together solve a fraction of the problen. The other parts of the problem are interfacing with classic c, c++ libraries and handling different hardware and different OSes. It is not even funny how tricky it is to use the same GPU/CUDA versions but with different CPU architectures and hopefully most people dont need to be exposed to it. Sometimes parts of the stack depends on a different version of a c++ li…

We do something similar with a mix of C++, Fortran, and CUDA dependencies. Using https://cibuildwheel.pypa.io/en/stable/ and the repair functionality to restrict the manylinux to something sensible seems to have handled the complexity - while we mostly use Debian and Ubuntu the Arch folks seemed OK too.

We want to share the wheels more smoothly though and having been looking at pyx for that. Seems promising.

Post reply on HN