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

421–430 of 479 posts

Re: PYX: The next step in Python packaging

#421

Post by senko »

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

> there are dozens of tools/concepts related to packaging ... Why is that hard for the Python community to come up with a single tool to rule them all?

They have: uv

> Don't understand how a private company like Astral is leading here

They wrote the single tool to rule them all.

Re: PYX: The next step in Python packaging

#422

Post by dataflow »

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…

I think the only way you can alleviate people's concerns here is by legally binding the company in a way that would adequately address those concerns. Which I don't recall ever seeing any company attempt in such a scenario, probably because it obviously devalues the company as it restricts what a potential future buyer could do with it. Which is exactly why some people don't buy such pinky promises.

Re: PYX: The next step in Python packaging

#423

Post by quotemstr »

zahlman wrote: post #413
imtringued wrote: post #364

Earlier quoted context omitted.

>FWIW, as a pip maintainer, I don't strongly agree with this statement, I think if pip had the same full time employee resources that uv has enjoyed over the last year that a lot of these issues could be solved. No. This something people tell each other, that it's a lack of resources, but in reality almost all OSS projects with long standing flaws don't have a resources problem. They have a prioritization problem, wh…

> They have a prioritization problem This is what forks are for. Alternately, money would probably help. Otherwise it's a bit rude to impose your priorities on others. Perhaps some larger projects lose track of what they intended to prioritize. This is also a resources problem. There's nobody available to do management (and probably also not a social structure internally that would allow for it). > because of how "im…

imtringued is right though. Obstinate maintainership is a real failure mode of open source (and other) projects and it's often true that patch rejections involving phrases like "maintenance burden" are often pretextual. It's a shame to have to resort to creative destruction to improve things. Forks have a low success probability.

Re: PYX: The next step in Python packaging

#424

Post by dcreager »

aragilar wrote: post #368
JimDabell wrote: post #328

Earlier quoted context omitted.

Frankly, it’s weird . You can find this business model all over the open-source world but for some reason Astral in particular is singled out for way more criticism on this than anything else I’ve seen, despite being unambiguously great contributors who have never put a foot wrong as far as I can tell. Microsoft – who invented embrace, extend, and extinguish – own NPM, but I don’t see people wringing their hands over…

NPM has always been commercial (rather than managed by a foundation), and it was nominally acquired by GitHub rather than Microsoft, so at some level as long as GitHub is not causing issues (noting the recent GitHub changes should maybe also imply some consideration of problems for NPM), NPM is "safe". Astral on the other hand has basically been rewrites in Rust of existing community-based open source tools, for whic…

> competing with PyPI

pyx doesn't compete with PyPI; it's a private registry that companies can use e.g. to host internal-only packages, or to provide curated views of things like PyPI for compliance reasons.

> making changes which seemingly require their client (uv) be used

That's an explicit non-goal: "You won't need to use pyx to use uv, and you won't need to use uv to use pyx."

Re: PYX: The next step in Python packaging

#425

Post by pama »

northzen wrote: post #313
pama wrote: post #235

Earlier quoted context omitted.

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…

Why don't you use pixi?

Pixi inherited some ot the bad designs from conda, and conda clearly hadnt been close to solving python packaging either and was digging itself into a black hole over time.

Re: PYX: The next step in Python packaging

#426

Post by woodruffw »

nilamo wrote: post #420
woodruffw wrote: post #275

Earlier quoted context omitted.

> it doesn't seem like printing a more useful error message to them should be that hard. I think the existing error message is useful: $ pip search foo ERROR: XMLRPC request failed [code: -32500] RuntimeError: PyPI no longer supports 'pip search' (or XML-RPC search). Please use https://pypi.org/search (via a browser) instead. See https://warehouse.pypa.io/api-reference/xml-rpc.html#deprecated-methods for more informa…

That is a nicer message than I remember. I don't have an issue with that. It let's you know it doesn't work, that it will never work, and provides links to an alternative and more information. It either used to do fewer of those, or my memory is Swiss cheese, but I remember needing to search for the why's and alternatives.

There was a period when the error was a stack trace. But that was pretty brief, and happened before PyPI moved more "officially" towards not supporting the search API.

I think part of the confusion here (which is reasonable IMO) is that pip has a huge version tail, and so people report error messages and behaviors that have been fixed for years. This is one of the challenges that I think gets under-appreciated about pip's maintenance.

Re: PYX: The next step in Python packaging

#427

Post by sporeray »

codethief wrote: post #388
alexshagov wrote: post #357

I personally use Nixpkgs to fully isolate python installation on per project basis. And inside this isolated env, once python is built, usually using pip is enough and works well This way, !each of my repositories has its own nix file defining the list of dependencies and it can easily be built per system as well

I love Nix as much as the next guy, but I also need my coworkers to be able to get things to work on their non-NixOS machines. Have you found an easy way to have Nix install packages through uv (from a pyproject.toml / uv.lock files)? Right now I just do programs.nix-ld.enable = true; and use uv completely separately from Nix.

uv2nix is great from my experience https://github.com/pyproject-nix/uv2nix

Re: PYX: The next step in Python packaging

#428

Post by Kevcmk »

hexo wrote: post #393
rmonvfer wrote: post #356

To be honest, this was just a matter of time. As a long time Python developer, I just can’t wrap my head around the lack of something like this. GitHub was going to get hosted packages for Python but never did because it “didn’t align with their strategy objectives and a reallocation of resources” [1] (or some other similar corpospeak) Astral is a great company and I think we can’t question what they’ve achieved and…

to be honest. ill never use uv. python ecosystem tools should be in python.

Definitely has never seen/used uv

Re: PYX: The next step in Python packaging

#429

Post by cpgxiii »

zahlman wrote: post #413
imtringued wrote: post #364

Earlier quoted context omitted.

>FWIW, as a pip maintainer, I don't strongly agree with this statement, I think if pip had the same full time employee resources that uv has enjoyed over the last year that a lot of these issues could be solved. No. This something people tell each other, that it's a lack of resources, but in reality almost all OSS projects with long standing flaws don't have a resources problem. They have a prioritization problem, wh…

> They have a prioritization problem This is what forks are for. Alternately, money would probably help. Otherwise it's a bit rude to impose your priorities on others. Perhaps some larger projects lose track of what they intended to prioritize. This is also a resources problem. There's nobody available to do management (and probably also not a social structure internally that would allow for it). > because of how "im…

> The developers will always be in a better position than end users to assess the long-term maintenance impact.

At best developers may be in a better position to assess long-term consequences. The history of major software projects is also the history of many projects making technical decisions that look good in the short-term but which turn out to impede actually achieving the desired features/performance/etc, and thus lead to major refactors/rewrites.

Re: PYX: The next step in Python packaging

#430

Post by miraculixx »

rmonvfer wrote: post #356

To be honest, this was just a matter of time. As a long time Python developer, I just can’t wrap my head around the lack of something like this. GitHub was going to get hosted packages for Python but never did because it “didn’t align with their strategy objectives and a reallocation of resources” [1] (or some other similar corpospeak) Astral is a great company and I think we can’t question what they’ve achieved and…

Anaconda solved the same problem ~10+ years ago already.
Post reply on HN