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.
PYX: The next step in Python packaging
431–440 of 479 posts
Re: PYX: The next step in Python packaging
#432All 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.
Re: PYX: The next step in Python packaging
#433> Why is it so hard to install PyTorch, or CUDA, or libraries like FlashAttention or DeepSpeed that build against PyTorch and CUDA? This is so true! On Windows (and WSL) it is also exacerbated by some packages requiring the use of compilers bundled with outdated Visual Studio versions, some of which are only available by manually crafting download paths. I can't wait for a better dev experience.
Re: PYX: The next step in Python packaging
#434Soon: there are 14 competing Python packaging standards. This is a joke, obviously. We've had more than 14 for years.
Python packaging has a lot of standards, but I would say most of them (especially in the last decade) don't really compete with each other. They lean more towards the "slow accretion of generally considered useful features" style. This itself is IMO a product of Python having a relatively healthy consensus-driven standardization process for packaging, rather than an authoritative one. If Python had more of an authori…
That said, it'd be nice if pip (or some PSF-blessed successor) adopted a model more similar to that offered by poetry (and formerly, pipenv, and now, I guess, uv) at least for package locking. `pip freeze > requirements.txt` isn't fit for purpose in the age of supply chain attacks, unfortunately, and PyPI already offers a reasonably workable backend for this model, whether the community at-large agrees to this or not. There are objective benefits (biggest one being better code integrity guarantees) that outweigh the objective (largely, performance-related) drawbacks.
Re: PYX: The next step in Python packaging
#435I'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,…
Re: PYX: The next step in Python packaging
#436To 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.
most of the stuff in the python ecosystem have a core built in C, including the language itself.
Re: PYX: The next step in Python packaging
#437To 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.
Re: PYX: The next step in Python packaging
#438Earlier quoted context omitted.
The problem for me: a non-python developer, is that I just don't know what to do, ever, to run an existing script or program. It seems every project out there uses a different package manager, a different version of python, a different config file to set all of that up. Most of the time, I just have a random .py file somewhere. Sometimes it's a full project that I can look at and find out what package manager it's us…
I believe what is missing is a way of distributing apps. You face similar issues if you get the C++ source of a random program - there are quite a few build systems in use! However, the compiled program can often just be zipped and shipped, somehow.
Re: PYX: The next step in Python packaging
#439If uv can install a Python version in 32ms (a time that I saw and confirmed just this morning), then sign me up.
Re: PYX: The next step in Python packaging
#440Earlier quoted context omitted.
I don't know; I was looking at TS tutorials the other day and there seemed to be at least half a dozen "bundlers" with different tutorails suggesting different ones to use. It took me a while to figure out I could just directly invoke "tsc" to generate javascript from typescript.
Yeah Typescript is maybe not the best example. Go, Rust and Zig get this right though. And Deno, which is based on Typescript.
I'm still not convinced that the built-in vendor support added in Go 1.5 wasn't intentionally made incompatible with the community-developed solutions out of some weird kind of spite. Why didn't they just use "./vendor/src" like all of the existing tools were using? (Remember that Go was written by plan9 folks, so making a "src" symlink didn't work. In fact, the Go compiler dislikes symlinks in most places -- pre-modules the unholy things you had to do with GOPATH were awful.)