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

371–380 of 479 posts

Re: PYX: The next step in Python packaging

#371

Post by imtringued »

hulitu wrote: post #282
Eduard wrote: post #224

Earlier quoted context omitted.

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…

Your comment shows the sad state of software quality those days. Rust is the same, move fast and break things. And lately also Mesa started to suffer from the same disease. You basically need, those days, the same build env like the one on the developer's machine or the build will fail.

Bad software quality is when you update your software frequently.

Instead, we should always choose the common denominator of the most obsolete software platform imaginable. If there is an OS that has not been maintained for several decades, then that is the baseline we should strive to support.

Using an operating system with old libraries and language runtimes is not a personal preference with the consequences of restricting oneself to older software versions, no, it is a commandment and must not be questioned.

Re: PYX: The next step in Python packaging

#372

Post by wrasee »

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…

The uncertainly over a future rug pull is always real, but in reality I wonder if the actual reason for people's hesitancy is more than just that. In reality I suspect it's closer to one of simply identity and the ownership model itself. Just the very idea that core tooling you depend on is in the hands of a commercial company is enough to many back off in a way one might not be when the tooling is in the hands of a broader community that one can support on more equal terms.

@woodruffw I love your quote above that commits you to your open source base and I'm rooting for you. But how about an approach that commits you to this sentence in a more rigorous and legal way, and spin off your open source tooling to a separate community-based entity? Of course, upon that you can continue to maintain sufficient representation to make Astral's commercial products the natural progression and otherwise the model remains the same. That would be a significant transfer of control, but it is that very transfer that would get a overwhelming response from the community and could really unblock these great tools for massive growth.

I work a lot with LLVM/Clang and whilst i know Apple and Google are significant contributors I feel confident that LLVM itself exists outside of that yet accept that e.g. Apple's contributions afford them weight to steer the project in ways that match their interests in e.g. Swift and Apple tooling.

Re: PYX: The next step in Python packaging

#373

Post by codethief »

krupan wrote: post #35
o11c wrote: post #28

Earlier quoted context omitted.

The entire reason people choose "permissive licenses" is so that it won't last forever. At best, the community can fork the old version without any future features. Only viral licenses are forever.

I think you are making a good point, but please don't use the old Steve Baller FUD term, "viral." Copyleft is a better term

Politics aside, "copyleft" originates from a pun and is hardly self-explanatory, whereas "viral" is.

Re: PYX: The next step in Python packaging

#374

Post by aragilar »

woodruffw wrote: post #277
callc wrote: post #253

Earlier quoted context omitted.

Do you really think Python’s consensus-driven language development is better than authoritarian? I am honestly tired of the Python packing situation. I breathe a sigh of relief in language like Go and Rust with an “authoritative” built-in solution. I wouldn’t mind the 30 different packaging solutions as long as there was authoritative “correct” solution. All the others would then be opt-in enhancements as needed. I g…

> I breathe a sigh of relief in language like Go and Rust with an “authoritative” built-in solution. I don't know about Go, but Rust's packaging isn't authoritative in the sense that I meant. There's no packaging BDFL; improvements to Rust packaging happen through a standards process that closely mirrors that of Python's PEPs. I think the actual difference between Rust and Python is that Rust made the (IMO correct) d…

Was not setuptools the single tool for package management? It provided both the installer plus hooks to define packages and manage the install (plus eggs to try to manage the path). That doesn't mean the choices were the right ones (the package definition being the only thing to survive), but it seems that while cargo has the mindshare for pure-rust, when there's the need for integration with other ecosystems (as is the biggest challenge for Python), people need to switch to using meson or bazel and there appears to be some issues there.

Re: PYX: The next step in Python packaging

#375

Post by aragilar »

ohmahjong wrote: post #355
rcleveng wrote: post #300

Just try using ux with Google Artifact Registry and AWS CodeArtifact. You need the username in the URL with GAR and you need it in the environment variable with AWS. I'm not sure who's causing the pain with using uv with private repositories (but I'd bet it's uv), but they are selling a solution to that pain. Full disclosure, uv rocks and is way better than poetry, setuptools and whatever complicated and non-zen way…

In my experience (albeit from about 4 years ago) having some kind of private package with pipenv (or even plain pip) was really annoying. We went the route of a private repo on Github rather than a private package repository, which maybe set us up for exactly that annoyance.

I find this strange, I always have private repositories using devpi (which also acts as a caching mirror) and it's easy to configure pip.

Re: PYX: The next step in Python packaging

#376

Post by threatofrain »

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…

The hosting and administration part is what’s expensive and can’t be free and open source except when someone pays for it. So is npm open source? Whether it is or isn't doesn't matter as much as whether Microsoft continues to pay the bill.

Re: PYX: The next step in Python packaging

#377

Post by physicsguy »

int_19h wrote: post #193
rob wrote: post #55

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?

Continuum has been doing something very similar with Anaconda, and they've been around for over a decade now.

And Enthought before them...

Re: PYX: The next step in Python packaging

#378

Post by codethief »

efitz wrote: post #279
fragmede wrote: post #254

Earlier quoted context omitted.

> pip started to warn me that I couldn't globally install packages anymore Yeah I had that on my work computer. I just created a venv and source that in my .bashrc.

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.

Re: PYX: The next step in Python packaging

#379

Post by physicsguy »

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

It's almost all largely because of compiled packages.

What happens in Go/TS when you want to use a C library underneath that's dynamically linked? Oh wait, there's no mechanism in it's package manager to support this, so it's assumed it's installed already, or in Go, C code is bundled instead. This is the problem all the Python packaging stuff above has tried to solve.

Re: PYX: The next step in Python packaging

#380

Post by aragilar »

forrestthewoods wrote: post #126
zahlman wrote: post #79

Earlier quoted context omitted.

> Why is it able to solve the Python runtime dependency problem? I thought uv had kinda already solved that? The dependencies in question are compiled C code that Python interfaces with. Handling dependencies for a graph of packages that are all implemented in pure Python, is trivial. C never really solved all the ABI issues and especially for GPU stuff you end up having to link against very specific details of the l…

> especially for GPU stuff you end up having to link against very specific details of the local architecture. Hrm. This doesn’t sound right to me. Any project should target a particular version of Cuda and then the runtime machine simply needs to have that version available. Right? > a lot of people would like to have packages that use pre-installed dependencies that came with the system Those people are wrong. Every…

You are assuming you are allowed to choose which CUDA runtime you can use.
Post reply on HN