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

261–270 of 479 posts

Re: PYX: The next step in Python packaging

#261

Post by giancarlostoro »

ilvez wrote: post #70
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…

Do I get it right that this issue is within Windows? I've never heard of the issues you describe while working with Linux.. I've seen people struggle with MacOS a bit due to brew different versions of some library or the other, mostly self compiling Ruby.

I had issues on Mac, Windows and Linux... It was obnoxious. It led me to adopt a very simple rule: if I cannot get your framework / programming language up and running in under 10 minutes (barring compilation time / download speeds) I am not going to use your tools / language. I shouldn't be struggling with the most basic of hello worlds with your language / framework. I don't in like 100% of the other languages I already use, why should I struggle to use a new language?

Re: PYX: The next step in Python packaging

#262

Post by zanie »

alisonatwork wrote: post #218
anitil wrote: post #176

Earlier quoted context omitted.

I agree, now I just use uv and forget about it. It does use up a fair bit of disk, but disk is cheap and the bootstrapping time reduction makes working with python a pleasure again

I recently did the same at work, just converted all our pip stuff to use uv pip but otherwise no changes to the venv/requirements.txt workflow and everything just got much faster - it's a no-brainer. But the increased resource usage is real. Now around 10% of our builds get OOM killed because the build container isn't provisioned big enough to handle uv's excessive memory usage. I've considered reducing the number of…

Please open an issue with some details about the memory usage. We're happy to investigate and feedback on how it's working in production is always helpful.

(I work on uv)

Re: PYX: The next step in Python packaging

#263

Post by giancarlostoro »

awesome_dude wrote: post #68
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…

Lets be honest here - whilst some experiences are better/worse than others, there doesn't seem to be a dependency management system that isn't (at least half) broken. I use Go a lot, the journey has been - No dependency management - Glide - Depmod - I forget the name of the precursor - I just remembered, VGo - Modules We still have proxying, vendoring, versioning problems Python: VirtualEnv Rust: Cargo Java: Maven an…

NuGet for C# has always been fantastic, and I like Cargo, though sometimes waiting for freaking ever for things to build does kill me on the inside a little bit. I do wish Go had a better package manager trajectory, I can only hope they continue to work on it, there were a few years I refused to work on any Go projects because setup was a nightmare.

Re: PYX: The next step in Python packaging

#264

Post by fragmede »

woodruffw wrote: post #161
nilamo wrote: post #158

Earlier quoted context omitted.

Does that seem like a real solution to you? That it's ok to represent a never-functional operation as one that might maybe work? ...because it could work of you jump through a bunch of undocumented hoops? It's so wild to me that so many people are apparently against making a user-friendly update. The whole thing seems very against pep8 (its surprising, complicated, non-specific, etc)

I don't know what to tell you; I just gave an example of it being functional for a subset of users, who don't deserve to be broken just because it's non-functional on PyPI. Nobody wants anything to be user-unfriendly. You're taking a very small view into Python packaging and extending it to motives, when resources (not even financial ones) are the primary challenge.

Is code to detect when the user is not in that subset and say that it doesn't work really really hard for some non-obvious reason? If the default case for the vast majority of users doesn't work, it doesn't seem like printing a more useful error message to them should be that hard.

Re: PYX: The next step in Python packaging

#265

Post by giancarlostoro »

poly2it wrote: post #72
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 Nix? https://nixos.org

I'm on Arch these days, but nix would have maybe helped, but this was 2010s where as far as I remember, nobody was talking about NixOS.

Re: PYX: The next step in Python packaging

#267

Post by aledalgrande »

bastawhiz wrote: post #204
runningmike wrote: post #103

All python packaging challenges are solved. Lesson learned is that there is not a single solution for all problems. getting more strings attached with VC funded companies and leaning on their infrastructure is a high risk for any FOSS community.

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…

Man I used python sparingly over the years and I still had to deal with all those package manager changes. Worse than the JS bundling almost?

Re: PYX: The next step in Python packaging

#268

Post by nerdponx »

twelvechairs wrote: post #233
6thbit wrote: post #127

Earlier quoted context omitted.

Thanks that’s bit less cryptic than the linked page. Still don’t get how they are solving what they claim to solve.

I'm guesssing from the UV page [0] its mainly if the speed of pip is a problem for you? [0] https://docs.astral.sh/uv/

There are a bunch of problems with PyPI. For example, there's no metadata API, you have to actually fetch each wheel file and inspect it to figure out certain things about the packages you're trying to resolve/install.

It would be nice if they contributed improvements upstream, but then they can't capture revenue from doing it. I guess it's better to have an alternative and improved PyPI, than to have no improvements and a sense of pride.

There is a lot of other stuff going on with Pyx, but "uv-native metadata APIs" is the relevant one for this example.

Re: PYX: The next step in Python packaging

#269

Post by progval »

Eduard wrote: post #224
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…

I started with "sudo apt install python" a long time ago and this installed python2. This was during the decades-long transition from python2 to python3, so half the programs didn't work so I installed python3 via "sudo apt install python3". Of course now I had to switch between python2 and python3 depending on the program I wanted to run, that's why Debian/Ubuntu had "sudo update-alternatives --config python" for ma…

I started at about the same time you did, and I've never seen an instance of software expecting a Python version newer than what is in Debian stable. It happens all the time for Nodejs, Go, or Rust though.

Re: PYX: The next step in Python packaging

#270

Post by fastball »

megamix wrote: post #266

No Thanks. For majority of my use case pip is just fine. I’m not here to chase time just to live life

Strange to reject something when you don't even understand what it is.

PYX is a package registry, and therefore an alternative to PyPI (like how JSR is an alternative to NPM).

The alternative to `pip` that Astral has built is called `uv`. Feel free to not use that either, but personally I'd consider it if I were you. It has full pip compatibility (with significantly more speed), and many other nice features besides.

Post reply on HN