uv doesn't solve all this, but it's reduced the amount of ways things can go wrong by a lot. And it being fast means that the feedback-loop is much quicker.

I think it's little recognized that there is a scaling limit for snapshots. If you have 20 people developing 20 project and they are co-located in the same room with the server builds work 50-80% of the time and people think it's fine. If you're the one guy who is remote and has a slow connection, builds work 0% of the time. The problem is that at slightly different times you get slightly different snapshots that aren't compatible with each other -- it's a scaling problem because if you add enough developers and enough projects it will eventually get you.

I've worked at other places when the mvn clean was necessary every time; other developers thought this shouldn't be necessary and I was a doofus except I was able to make consistent progress like a ratchet on the project and get it done and they weren't.

Where I am now mvn is just fine, whenever it screws up there's a rational explanation and we're doing it wrong.

Node/NPM was a poster child of an ecosystem where projects break three times a week, due to having too many transitive dependencies that are being updated too often.

It used to prior to npm 5 when lockfiles were introduced (yarn introduced lockfiles earlier).

That's always one major thing I saw breaking old builds: old binaries stop being hosted, forcing you to rebuild them from old source, which no longer builds under current toolchains - making you either downgrade the toolchain that itself may be tricky to set up, or upgrade the library, which starts a cascade of dependency upgrades.

It's not like Node projects are distributed with their deps vendored; there's too much stuff in node_modules.

Yes it does, that's the whole point. You can still go and install the first version of express ever put on npm from 12 years ago. You can also install any of the 282 releases of it that have ever been put on npm since then. That's the whole point of a registry, it wouldn't be useful if things just disappeared at some random point in time.

The only packages that get removed are malware and such, and packages which the vendor themselves manually unpublish [0]. The latter has a bunch of rules to ensure packages that are actually used don't get removed, please see the link below.

[0] https://docs.npmjs.com/policies/unpublish

Yes you can find edge cases with problems. Using this as an argument for "breaks 3 times per week" does not hold.

(Also note that outside the web/mobile space, projects that weren't updated in a year are still young, not old. "Old" is more like 5+ years.)

The two things are related. If your typical project has a dependency DAG of 1000+ projects, a bug or CVE fix somewhere will typically cause a cascade of potentially breaking updates to play out over multiple days, before everything stabilizes. This creates pressure for everyone to always stay on the bleeding edge; with a version churn like this, there's only so many old (in the calendar sense) package dists that people are willing to cache.

This used to be a common experience some years back. Like many others, I gave up on the ecosystem because of the extreme fragility of it. If it's not like that anymore, I'd love to be corrected.

The non-trivial exception being if some dependecy was downloading resources on the fly (maybe like a browser compat list) or calling system libraries (eg running shell commands)

uv felt a bit immature at the time, but sounds like it’s way better now. I really want to try it out... but Poetry just works, so I don’t really have an incentive to switch just yet. (Though I’ve switched from FlakeHeaven or something to Ruff and the difference was heaven and hell! Pun in’tended.)

uv init

uv sync

and you're done

I'd say if you do not run into the pitfalls of a large python codebase with hundreds of dependencies, you'll not get the bigger argument people are talking about.

That said, I do wish uv had `uv activate`. I like just working in the virtualenv without having to `uv run` everything.

    function __auto_fab --on-variable PWD
        iterm2_print_user_vars
        if [ -d "fabfile" ]
            if [ -d "fabfile/.venv" ]
                if not set -q done_fab
                    and not set -q VIRTUAL_ENV
                    echo -n "Starting fabfile venv... "
                    pushd fabfile > /dev/null
                    source .venv/bin/activate.fish  --prompt="[fab]"
                    popd > /dev/null
                    set -g done_fab 1
                    echo -e "\r Fabfile venv activated         "
                end
            else
                echo "Run gofab to create the .venv"
            end
        end
    end

    function __auto_venv --on-variable PWD
        if [ -d ".venv" ]
            if not set -q done_venv
                echo -n "Starting venv... "
                source .venv/bin/activate.fish  --prompt="[venv]"
                set -g done_venv 1
                echo -e "\r Venv activated         "
            end
        end
    end

These live in ~/.config/fish/conf.d/events.fish

[1] https://github.com/direnv/direnv/wiki/Python

I... what? Python is a beautiful way to evolve beyond the troglodyte world of sh for system scripts. You are seriously missing out by being so pertinently against it.

Don't get me wrong, Rust is great and I use it too, but for very different purposes than (system) scripts.

And what if there are no binaries yet for my architecture, will it compile them, including all the dependencies written in C?

Instead there is pixi, which is similar in concept to uv but for the conda-forge packaging ecosystem. Nix and guix are also language-agnostic package managers that can do the job.

If you want to build shapely against your own version of GEOS, then you fall outside of what uv does. What it does in that case is download the all build tool(s) specified by shapely (setuptools and cython in this case) and then hands over control to that tool to handle the actual compiling and building of the library. It that case it is up to the creator of the library to make sure the build is correctly defined and up to you to make sure all the necessary compilers and header etc. are set up correctly.

[1]: https://github.com/spack/spack/blob/develop/var/spack/repos/... [2]: https://github.com/spack/spack/blob/develop/var/spack/repos/...

But conda-forge packages (just like PyPI packages, or anything that does install-time dependency resolution really) are untestable by design, so if you care for reliably tested packages you can take a look at nix or guix and install everything through that. The tradeoff with those is that they usually have less libraries available, and often only in one version (since every version has to be tested with every possible version of its dependencies, including transitive ones and the interpreter).

All of these tools have a concept similar to environments, so you can get the right version of GEOS for each of your projects.

Nix/guix sound interesting. But one of my systems is an nVidia Jetson system, where I'm tied to the system's libc version (because of CUDA libraries etc.) and so building things is a bit trickier.

It should also respect any CFLAGS and LDFLAGS you set, but I haven't actually tested that with uv.

On Alpine and Arch Linux? Exactly nothing.

On Debian/Ubuntu? maybe the convoluted packaging process, but that's on you for choosing those distributions.

    uv build
    Building source distribution...
    running egg_info
    writing venv.egg-info/PKG-INFO
    Successfully built dist/venv-0.1.0.tar.gz
    Successfully built dist/venv-0.1.0-py3-none-any.whl

A new and immature interpreter is going to have other problems:

- Lack of compatibility with CPython - Not up to date with latest version features - Incompatibility with CPython extensions

RustPython is a cool project, but it's not reached the big time yet.

Python is going through package managers like JS goes through trends like classes-everywhere, hooks, signals etc