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

51–60 of 479 posts

Re: PYX: The next step in Python packaging

#51

Post by orra »

yoavm wrote: post #24
metalliqaz wrote: post #20

> Waitlist > Private registry ouch.

I actually think this is great. If Astral can figure out a way to make money using a private registry (something that is used mainly by companies), then they'll have to resources to keep building their amazing open-source projects — Ruff and uv. That's a huge win for Python.

In particular I think it's nice for uv and ruff to remain open source, not open core. And as you say, companies always need paid private registries, for their internal software. A true win-win.

Re: PYX: The next step in Python packaging

#52

Post by lenerdenator »

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

> In Python there are dozens of tools/concepts related to packaging: pip, easy_install, setuptools, setup.py, pypy, poetry, uv, venv, virtualenv, pipenv, wheels,

Some of those are package tools, some are dependency managers, some are runtime environments, some are package formats...

Some are obsolete at this point, and others by necessity cover different portions of programming language technologies.

I guess what I'm saying is, for the average software engineer, there's not too many more choices in Python for programming facilities than in Javascript.

Re: PYX: The next step in Python packaging

#53

Post by nurettin »

giancarlostoro wrote: post #45
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 ov…

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.

Re: PYX: The next step in Python packaging

#54

Post by charliermarsh »

m4r71n wrote: post #36

What does GPU-aware mean in terms of a registry? Will `uv` inspect my local GPU spec and decide what the best set of packages would be to pull from Pyx? Since this is a private, paid-for registry aimed at corporate clients, will there be an option to expose those registries externally as a public instance, but paid for by the company? That is, can I as a vendor pay for a Pyx registry for my own set of packages, and t…

> Will `uv` inspect my local GPU spec and decide what the best set of packages would be to pull from Pyx?

We actually support this basic idea today, even without pyx. You can run (e.g.) `uv pip install --torch-backend=auto torch` to automatically install a version of PyTorch based on your machine's GPU from the PyTorch index.

pyx takes that idea and pushes it further. Instead of "just" supporting PyTorch, the registry has a curated index for each supported hardware accelerator, and we populate that index with pre-built artifacts across a wide range of packages, versions, Python versions, PyTorch versions, etc., all with consistent and coherent metadata.

So there are two parts to it: (1) when you point to pyx, it becomes much easier to get the right, pre-built, mutually compatible versions of these things (and faster to install them); and (2) the uv client can point you to the "right" pyx index automatically (that part works regardless of whether you're using pyx, it's just more limited).

> Since this is a private, paid-for registry aimed at corporate clients, will there be an option to expose those registries externally as a public instance, but paid for by the company? That is, can I as a vendor pay for a Pyx registry for my own set of packages, and then provide that registry as an entrypoint for my customers?

We don't support this yet but it's come up a few times with users. If you're interested in it concretely feel free to email me (charlie@).

Re: PYX: The next step in Python packaging

#55

Post by rob »

Is there a big enough commercial market for private Python package registries to support an entire company and its staff? Looks like they're hiring for $250k engineers, starting a $26k/year OSS fund, etc. Expenses seem a bit high if this is their first project unless they plan on being acquired?

Re: PYX: The next step in Python packaging

#57

Post by WesolyKubeczek »

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?

Whatever I would say at this point about PyPA would be so uncharitable that dang would descend on me with the holy hammer of banishment, but you can get my drift. I just don't trust them to come out with good tooling. The plethora they have produced so far is quite telling.

That said, pip covers 99% of my needs when I need to do anything with Python. There are ecosystems that have it way worse, so I count my blessings. But apparently, since Poetry and uv exist, my 99% are not many other people's 99%.

If I wanted to package my Python stuff, though, I'm getting confused. Is it now setup.py or pyproject.toml? Or maybe both? What if I need to support an older Python version as seen in some old-but-still-supported Linux distributions?

> They should remove the "There should be one-- and preferably only one --obvious way to do it." from the Python Zen.

Granted, tooling is different from the language itself. Although PyPA could benefit from a decade having a BDFL.

Re: PYX: The next step in Python packaging

#58

Post by ActorNightly »

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.

I agree. If any of the stuff was worthwhile to pursue, it would be merged into pip.

Re: PYX: The next step in Python packaging

#59

Post by Y_Y »

cr125rider wrote: post #21
Myrmornis wrote: post #9

I wonder whether it will have a flat namespace that everyone competes over or whether the top-level keys will be user/project identifiers of some sort. I hope the latter.

Once we learn to namespace things it’s gonna be so nice. Seems we keep re-learning that lesson…

  import io
  from contextlib import redirect_stdout as r
  b=io.StringIO()
  with r(b):import this
  print(b.getvalue().splitlines()[-1])
> Namespaces are one honking great idea -- let's do more of those!

Re: PYX: The next step in Python packaging

#60

Post by nickserv »

nurettin wrote: post #53
giancarlostoro wrote: post #45

Earlier quoted context omitted.

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

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.

Post reply on HN