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

361–370 of 479 posts

Re: PYX: The next step in Python packaging

#361

Post by sharpshadow »

nilamo wrote: post #104
ActorNightly wrote: post #58

Earlier quoted context omitted.

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

Pip is broken and has been for years, they're uninterested in fixing the search. Or even removing the search or replacing it with a message/link to the package index. imo, if pip's preference is to ship broken functionality, then what is/is not shipped with pip is not meaningful.

Your comment gave me an flashback to when I started programming and drag and dropped downloaded python packages into the packages folder instead of installing them.

Re: PYX: The next step in Python packaging

#362

Post by pepoluan »

stackskipton wrote: post #200
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…

They have no need to, current repos show everything is under MIT/Apache. They could close the source at any time and not worry about CLA. >bigger picture here is that Astral wants to build services as a product What services? pyx? Looks nice but I doubt my boss is going to pay for it. More likely they just say "Whatever, package is in PyPi, use that." UV, Ruff, Ty. Again, maybe they can get some data/quant firm who R…

It ultimately depends on a company's risk appetite.

Some companies specify that packages need to be hosted on their internal repository/artifactory, and for these companies, pyx might be a good tool.

Re: PYX: The next step in Python packaging

#363

Post by exasperaited »

arkh wrote: post #334
bastawhiz wrote: post #204

Earlier quoted context omitted.

Well I started with pip because it's what I was told to use. But it was slow and had footguns. And then I started using virtualenv, but that only solved part of the problem. So I switched to conda, which sometimes worked but wrecked my shell profile and often leads to things mysteriously using the wrong version of a package. So someone told me to use pipenv, which was great until it was abandoned and picked up by som…

Coming from the php ecosystem this kind of package manager problems feels crazy. Maybe Python and js people should just use composer too.

It is hilarious how Composer went from "haha, PHP has a package manager now, bless their hearts" to "why can't it work like Composer?"

I don't think PHP is perfect by any means but I don't dread using Composer, even in contexts like WP plugins where it is definitely not a "native" technology.

Re: PYX: The next step in Python packaging

#364

Post by imtringued »

notatallshaw wrote: post #92
zahlman wrote: post #74

Earlier quoted context omitted.

Pyx represents the server side, not the client side. The analogue in the pre-existing Python world is PyPI. Many ideas are being added to recent versions of pip that are at least inspired by what uv has done — and many things are possible in uv specifically because of community-wide standards development that also benefits pip. However, pip has some really gnarly internal infrastructure that prevents it from taking a…

> However, pip has some really gnarly internal infrastructure that prevents it from taking advantage of a lot of uv's good ideas (which in turn are not all original). 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. I'm not saying here that pip doesn't have…

>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, where they actively ignore and refuse to work on things that affect users every single day of usage.

There are features in FreeCAD that are straight up just broken that you hit every single day of using FreeCAD. When a simple low cost fix is suggested you get immense pushback, because of how "impure" the fix is despite being entirely cosmetic, also being reversible and having no long term impact on maintenance.

Progress happens when you sidestep those who block progress. That's what realthunder was doing and that's what Astral is doing with uv. No more bullshit excuses.

Re: PYX: The next step in Python packaging

#365

Post by Myrmornis »

almostgotcaught wrote: post #237
twarge wrote: post #234

The real pyx is an absolutely wonderful graphing package. It's like Tex in that everything looks wonderful and publication-quality. https://pyx-project.org/gallery/graph/index.html

there's something about these comments ("name-collision") that drives me up the wall. do y'all realize multiple things can have the same name? for example, did you know there are many people with exactly the same names: https://www.buzzfeed.com/kristenharris1/famous-people-same-n... and yet no one bemoans this (hospitals don't consult name registries before filling out birth certificates). that's because it's almost…

Agreed. I'm the author of a fairly popular dev environment project. Every so often you get people turning up enraged because I chose a name that some other project once used. In the situation I'm talking about it makes even less sense than pip -- it's a command-line executable. There's no one repository (although doesn't seem like Debian people would agree with that!). There's a multitude of package managers on different platforms. Furthermore, in case people hadn't noticed, there are these things called languages, countries, and cultures. There is no reason in general why there might not be package managers whose use is culturally or geographically non-uniform and perhaps entirely unfamiliar to those in other countries. So, what's the plan for checking whether a name is "taken" across human culture, history, and computing platforms? Silly out-dated notion.

Re: PYX: The next step in Python packaging

#366

Post by jjgreen »

thrown-0825 wrote: post #331
int_19h wrote: post #195

Earlier quoted context omitted.

Ruby is mostly used in web dev, where most if not all of your dependencies tend to be pure Ruby. Python is used heavily for DS/ML/AI, which is exactly the area where native code packages are necessary and prevalent. Worse yet is that those packages often involve GPU code, and things like CUDA bring their own complications. If you're writing web apps in Python, dependencies haven't really been a problem for a long tim…

Ruby libs have lots of c bindings. The reason python is a mess is because it became the default for academics and data scientists who have no real interest in code quality or maintainability and the rot just spread from there.

I've done a few Ruby/C and Python/C bindings, the APIs are worlds apart: I'd say Ruby's is like afternoon cocktails with a cultivated Swedish philosopher, Python's is the aftermath of a bar-room brawl where broken bottles were used.

Re: PYX: The next step in Python packaging

#368

Post by aragilar »

JimDabell wrote: post #328
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!

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 which there is always the question of how such work is funded. PYX (which is an interesting choice of name given the conflicts with pyrex/cython filenames) from what we can see here appears to be in a similar vein, competing with PyPI and making changes which seemingly require their client (uv) be used.

Anaconda/ContinuumIO was also treated with similar suspicion to Astral, so I don't think it's Astral in particular, it's more they both are operating in the part of the ecosystem where it is comparatively easy to lock out community-based open source tools (which the Python ecosystem appears to have been better at setting up and maintaining than the JS ecosystem).

Post reply on HN