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

401–410 of 479 posts

Re: PYX: The next step in Python packaging

#401

Post by benrutter »

ActorNightly wrote: post #58
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.

I'm assuming by pip you mean pypi (the package registry) - I think you're making the mistake of thinking it has a lot more resources than it does, because of how much it punches above its weight.

Pypi is powered by warehouse which has around 3 developers maintaining it[0]. They're doing an awesome job, but the funding and resource available to them are probably substantially less than Astral could have with a paid offering.

[0] https://github.com/pypi/warehouse/graphs/contributors

Re: PYX: The next step in Python packaging

#402

Post by LucasOe »

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.

Why?

Re: PYX: The next step in Python packaging

#403

Post by skydhash »

thedanbob wrote: post #112
chao- wrote: post #106

Earlier quoted context omitted.

I'm surprised to hear that. Ruby was the first language in my life/career where I felt good about the dependency management and packaging solution. Even when I was a novice, I don't remember running into any problems that weren't obviously my fault (for example, installing the Ruby library for PostgreSQL before I had installed the Postgres libraries on the OS). Meanwhile, I didn't feel like Python had reached the bar…

Bundler has always been the best package manager of any language that I've used, but dealing with gem extensions can still be a pain. I've had lots of fun bugs where an extension worked in dev but not prod because of differences in library versions. I ended up creating a docker image for development that matched our production environment and that pretty much solved those problems.

That's one of the reason I prefer a dev environment (either physical install or VM) that matches prod. Barring that I would go with with a build system (container-based?) that can be local. Otherwise it's painful.

Re: PYX: The next step in Python packaging

#404

Post by cgravill »

giancarlostoro wrote: post #263
awesome_dude wrote: post #68

Earlier quoted context omitted.

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.

The main NuGet was problematic for a long time e.g. not providing any control over transitive dependencies (like pip at the time). You had to use https://fsprojects.github.io/Paket/ if you wanted safe and consistent resolution. NuGet since got their act together and it’s not as flawed now.

Re: PYX: The next step in Python packaging

#405

Post by cyphar »

codethief wrote: post #378
efitz wrote: post #279

Earlier quoted context omitted.

Hahaha that is an awesome middle finger to pip :-)

Is it? I would have thought this is still in line with their goals. Your individual projects' venvs will still be fully separate.

No, they're saying that they have one venv they use for everything (i.e., it's basically a working "pip install --user").

I think it's a good thing that pip finally decided to refuse overwriting distro package paths (the alternative is far worse) but making "pip install --user" not work as well doesn't make sense.

Re: PYX: The next step in Python packaging

#406

Post by jpambrun »

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.

This is very close minded. It's best to avoid statements like that.

I feel like having a working python environment is not a great requirement to managing your python environment.

Re: PYX: The next step in Python packaging

#407

Post by westurner »

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…

Is this problem also solved by storing software artifacts in OCI container image registries that already support SLSA-compliant TUF signatures?

Re: PYX: The next step in Python packaging

#409

Post by zahlman »

mikepurvis wrote: post #245
zahlman wrote: post #232

Earlier quoted context omitted.

You could do worse than to start using --only-binary=:all: by default. (It's even been proposed as default behaviour: https://github.com/pypa/pip/issues/9140 ) Even if you can't actually install that way, it will point out the places where sdists are needed. In principle, separate metadata availability should still at least be possible for most sdists eventually . But I'm not the one calling the shots here.

For clarity, if I do pip install -r requirements.txt --dry-run --only-binary=:all:` Should I expect that to download only metadata and not whole wheels/sdists for everything? Or does that depend on everything in my requirements file being available as a wheel?

If there are things not available as a wheel, it should just fail (and highlight what failed).

Re: PYX: The next step in Python packaging

#410

Post by igortg »

physicsguy wrote: post #299
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…

Conda said all this as well, and solved the same issues you’re trying to - namely precompiled versions of difficult to build packages. It then went commercial. In the HPC space there are already Easybuild and Spack which make all the compiler tool chain and C and Fortran library dependency stuff very easy. They just haven’t taken off outside as they aim to solve cluster management problems but Spack is easy to self s…

Yes, it went commercial. But Conda is still free. And the community had built conda-forge to maintain packages. Conda + conda-forge can completly replace Anaconda for most people.

So even though they went commercial, they left pretty good things behind for the Open source community.

Post reply on HN