Many competent contributors have left or were silenced by the politicians. PyPI had multiple severe vulnerabilities. pip has no adequate story for the scientific ecosystem. Building from source via pip usually fails, unlike around 2010 when it usually worked.

The only thing that prevents lock-in is the religious zeal of most Python users to use anything presented by the PSF high priests, not technical merit.

The reason uv exists is the utter incompetence of PyPA.

That's just marketing. Only time will tell. I'll be very happy to be wrong

Until they change their minds. If they were serious about it, it would be part of PyCQA

Active state, that’s a name I’ve not heard in a long time. A long time.

Heh, Sonatype - Maven - Nexus, Gradle Inc - Gradle (both Java).

Most forks eventually die.

Yes, but only after fracturing the ecosystem even further unfortunately.

I think uv is one of the best examples of why not to start a new project in Python. I mean, depending on the project really, Python has its place. But if your project is anything like uv, uv proves you can't actually write an app like uv in Python. So for as great as uv is, its proximity to Python is a constant reminder of its shortcomings.

Indeed. It's interesting to compare the expectations of a new programming language today to just a decade ago for instance.

Pixi has also been such a breathe of fresh air for me. I think it's as big of a deal as UV (It uses UV under the hood for the pure python parts).

It's still very immature but if you have a mixture of languages (C, C++, Python, Rust, etc.) I highly recommend checking it out.

Pixi is what FreeCAD is now using. (Along with Rattler).

It makes building FreeCAD pretty trivial, which is a huge deal considering FreeCAD’s really complex Python and non-python, cross-platform dependencies.

Yep, pixi is game changing. Especially for AI/ML, the ability to deal with non-python dependencies in nearly as fast a way as `uv` is huge. We have some exciting work leveraging the lower level primatives pixi uses we hope to share more about soon.

This seems to pretty much cover the same use cases as Mise. Is that true?

This is something that uv advocates should pay attention to, there are always contexts that need different assumptions, especially with our every growing and complex pile of libraries and systems.

I wish the Python ecosystem would just switch to Rust. Things are nice over here… please port your packages to crates.

> I work professionally in ML and have not had to touch conda in the last 7 years. In an ML cluster, it is hopefully containerized and there is no need for that?

I wish my life had been like this. Unfortunately I always appear to end up needing to make this stuff work for everyone else (the curse of spending ten years on Linux, I suppose).

But then ML is a very broad church, and particularly if you're a researcher in a bigger company then I could see this being true for lots of people (again, i wish this was me).

Very common in education/research systems. Even the things which are containerised often have conda in them.

At least on my cluster, few if any workloads are containerized. We also have an EKS where folks run containerized, but that's more inference and web serving, rather than training.

It's still used in edu and research. Haven't seen it in working environments in quite some time as well.

uv does it by caching versions of packages so they can be shared across projects/environments. So you still have to store those multi-gig directories but you don't have so much duplication. If conda could do something similar that would be great

I'd argue bzip compression was a mistake for Conda. There was a time when I had Conda packages made for the CUDA libraries so conda could locally install the right version of CUDA for every project, but boy it took forever for Conda to unpack 100MB+ packages.

CUDA is part of our cluster install scripts, we don't manage that with uv or conda. To me, that should be system software that only gets installed once.

https://docs.astral.sh/uv/guides/integration/pytorch/#using-...

does that fit the bill?

There is also pixi (which uses uv for the python side of things) which feels like uv for conda.

conda (and its derivatives that are also “conda” now), and conda-forge specifically, are the best ways to install things that will work across operating systems, architectures, and languages - without having to resort to compiling everything.

Want to make sure a software stack works well on a Cray with MPI+cuda+MKL, macOS, and ARM linux, with both C++ and Python libraries? It’s possible with conda-forge.

Conda is much, much better for the C/Fortran/C++ parts of data science/machine learning workloads.

Like, I had real issues with GDAL and SQLite/spatialite on MacOS (easy on Linux) which uv was of no help with. I ended up re-architecting rather than go back to conda as uv is just that good (and it was early stage so wasn't that big of a deal).

I stay with it because last time I tried uv it was still directory/project focused vs. environment. With conda it doesn't matter where I am, I can activate any of my environments and run code

cuda-nvcc was a blocker for us but it looks like a stable version is coming to pypi

PyO3 + Maturn is fine, but it's a bit tedious if you have a big API. Some annoyances:

  - Enums with inner types require hacks
  - No clean way to make your Rust enums into Python enums
  - More boilerplate than you should have. I think I will have to write my own macros/helpers to solve. For example, you need getters and setters for each field. And the gotcha: You can't just macro them due to a PyO3 restriction.
  - No way to use other Python-exposed rust libs as dependencies directly. You have to re-expose everything. So, if your rust B lib depends on rust A, you will make a PyO3 Rust A package, but instead of re-using that in PyO3 Rust B, you will copy+paste your PyO3 Rust A boilerplate into PyO3 Rust B.

PyO3 and Maturin are excellent. I've been maintaining a Python-module-written-in-Rust for several years now, and it's been quite smooth.

I'd be interested in this too. I know it's possible, but haven't found a good guide on how to do it well and manage the multi-lang complexity.

Many people use PyO3 for that

I've programmed all those languages before (learned C in '87, C++ in 93, Go in 2015 or so) and to be honest, while I still love C, I absolutely hate what C++ has become, Go never appealed to me (they really ignored numeric work for a long time). Rust feels like somebody wanted to make a better C with more standard libraries, without going the crazy path C++ took.

NOW? with package managers

Having a directory like node_modules containing the dependencies is such an obviously good choice, it's sad how Python steering council actively resists this with what I find odd arguments.

I think a lot of the decades old farce of Python package management would have been solved by this.

https://peps.python.org/pep-0582/

https://discuss.python.org/t/pep-582-python-local-packages-d...

> This was always my issue with pip and venv: I don’t want a thing that hijacks my terminal and PATH ...

What's the "this" that is supposedly always your issue? Your comment is phrased as if you're agreeing with the parent comment but I think you actually have totally different requirements.

The parent comment wants a way to have Python packages on their computer that persist across projects, or don't even have a notion of projects. venv is ideal for that. You can make some "main" venv in your user directory, or a few different venvs (e.g. one for deep learning, one for GUIs, etc.), or however you like to organise it. Before making or running a script, you can activate whichever one you prefer and do exactly like parent commenter requested - make use of already-installed packages, or install new ones (just pip install) and they'll persist for other work. You can even switch back and forth between your venvs for the same script. Totally slapdash, because there's no formal record of which scripts need which packages but also no ceremony to making new code.

Whereas your requirements seem to be very project-based - that sounds to me like exactly the opposite point of view. Maybe I misunderstood you?

    > Python/pip though… Every time I need to containerize or setup a Python project for some arbitrary task, there’s always an issue with “Your Linux distro doesn’t support that version of Python anymore” [...]

(1) How old must the Python version of those projects be, to not be supported any longer with any decent GNU/Linux distribution?

(2) Are you not using official Python docker images?

(3) What's pip gotta do with a Python version being supported?

(4) How does that "Your Linux distro doesn’t support that version of Python anymore" show itself? Is that a literal error message you are seeing?

    > [...] demanding new —yes-destroy-my-computer-dangerously-and-step-on-my-face-daddy flags and crashing my automated scripts from last year

(1) Why are you not using virtual environments?

(2) You are claiming Node.js projects to be better in this regard, but actually they are just creating a `node_modules` folder. Why then is it a problem for you to create a virtual environment folder? Is it merely, that one is automatic, and the other isn't?

    > This was always my issue with pip and venv: I don’t want a thing that hijacks my terminal and PATH, flips my world upside down and makes writing automated headless scripts and systemd services a huge pain.

> demanding new —yes-destroy-my-computer-dangerously-and-step-on-my-face-daddy flags and crashing my automated scripts from last year.

Literally, my case. I recently had to compile an abandoned six-year-old scientific package written in C with Python bindings. I wasn’t aware that modern versions of pip handle builds differently than they did six years ago — specifically, that it now compiles wheels within an isolated environment. I was surprised to see a message indicating that %package_name% was not installed, yet I was still able to import it. By the second day, I eventually discovered the --no-build-isolation option of pip.

For not having to call 'source ...' in a Dockerfile, if you use the python executable from the virtualenv directly, then it will be as if you've activated that virtualenv.

This works because of the relative path to the pyenv.cfg file.

Conda is open source. Not sure what you mean about an EULA. There are some license agreements if you use Anaconda, but if you just use conda-forge you don't have any entanglements with Anaconda the company. (I agree the nomenclature is confusing.)

Exactly, and this is why we use virtual environments. Which then get dumped on by other people. People can't have it both ways, but they already have all the choices in Python's ecosystem. They just complain, because they are not aware how they can do it their way and didn't invest the time to nail down the workflow they like, or their workflow idea is self-contradictory.

My sentiment coming to Python after getting used to the DX of Node

https://uploads.dailydot.com/2024/04/damn-bitch-you-live-lik...

System package management is a mess in the first place, if you have a program that uses python then all the packages that it uses need to be installed globally, so you have python packages bundled as system packages which can conflict with that same package installed with pip.

I've never quite forgiven python for the time I tried to update it using yum, it failed which is then broke yum - not a fun place to end up.

Treating python as a project level dependency rather than a system level dependency is just an excellent design choice.

I'm not talking about the global environment. I want to be able to have whatever environments I want. But my point is that the environments are not in a 1-1 relationship with "projects".

Way to go to create non-reproducible results. Basically, nothing production ready is rolling out of that one.

If so, it's certainly not obvious. I mean look at the docs: https://docs.astral.sh/uv/getting-started/features/

I don't see anything resembling "environments" in the list of features or in the table of contents. In some sections there is stuff like "When working on a project with uv, uv will create a virtual environment as needed", but it's all about environments as tied to particular projects (and maybe tools).

You can use the `uv venv` and the `uv pip` stuff to create an environment and install stuff into it, but this isn't really different from normal venvs. And in particular it doesn't give me much benefit over conda/mamba.

I get that the project-based workflow is what a lot of people want, and I might even want it sometimes, but I don't want to be forced into foregrounding the project.

I think that user (like me until finding out just now) didn't know that you could make ad-hoc virtual environments with uv, and that instead you would have to make a directory with a pyproject.toml and install things into it by adding to that pyproject.toml

You can, but an "everything environment" is rarely to be recommended. How to do it: Make uv use the --active environment to install things. Before using uv, activate that environment.

Especially in research the project environment approach makes sense, where results don't mean much without reproducibility.

I'm not talking about wanting single-file scripts, but about having a "sandbox" environment in which various things can be messed with before abstracting anything out into a project.

It's not about single-file scripts, it's about having a "sandbox" environment in which various things can be messed with before abstracting anything out into a project.

Yup. I never even use activate, even though that's what you find in docs all over the place. Something about modifying my environment rubs me the wrong way. I just call ``./venv/bin/python driver.py`` (or ``./venv/bin/driver`` if you install it as a script) which is fairly self-evident, doesn't mess with your environment, and you can call into as many virtualenvs as you need to independently from one another.

``uv`` accomplishes the same thing, but it is another dependency you need to install. In some envs it's nice that you can do everything with the built-in Python tooling.

>> I also like how you can manage Python versions very easily with it. > > I still don't understand why people value this so highly, but so it goes.

Well I do need some way to install multiple python versions in parallel, and ideally the correct python version would be used in each project automatically. I used to use pyenv for this, which puts shims in your path so that it can determine which python executable to run on the fly, but I found that it was sometimes very slow, and it didn’t work seamlessly with other tools. Specifically pipenv seemed to ignore it, so I’d have to use a workaround to point pipenv to the path to the pyenv-installed python executable.

When one tool does both python installs and dependency/venv management, then it can make these work seamlessly together, and I don’t need to screw up my path to make the version selection work either.

If you have multiple python applications with different versions, it's nice to use the same version as deployed.

At least major and minor, patch is rarely needed for python.

I would very much like to know the reason why they named it bin/ here and Scripts/ there. To get some closure.

I agree, once I learned (early in my programming journey) what the PATH is as a concept, I have never had an environment problem.

However, I also think many people, even many programmers, basically consider such external state "too confusing" and also don't know how they'd debug such a thing. Which I think is a shame since once you see that it's pretty simple it becomes a tool you can use everywhere. But given that people DON'T want to debug such, I can understand them liking a tool like uv.

I do think automatic compiler/interpreter version management is a pretty killer feature though, that's really annoying otherwise typically afaict, mostly because to get non-system wide installs typically seems to require compiling yourself.

It does, Python has essentially solved it for years.

There are basically 0 other programming languages that use the "directory/shell integration activated virtual environment", outside of Python.

How does the rest of the world manage to survive without venvs? Config files in the directory. Shocking, really :-)))

raises hand I hate python.

I am a user of pip binaries. Every few years one of them breaks.

As far as I understand, developers never cared about pinning their dependencies and python is fast to deprecate stuff.

  $ uvx remt
      Built pygobject==3.54.5
      Built remt==0.11.0
      Built pycairo==1.28.0
  Installed 12 packages in 9ms
  Traceback (most recent call last):
    File "/home/user/.cache/uv/archive-v0/BLXjdwASU_oMB-R4bIMnQ/bin/remt", line 27, in <module>
    import remt
  File "/home/user/.cache/uv/archive-v0/BLXjdwASU_oMB-R4bIMnQ/lib/python3.13/site-packages/remt/__init__.py", line 20, in <module>
    import pkg_resources
  ModuleNotFoundError: No module named 'pkg_resources'

  $ uvx maybe
  × Failed to build `blessings==1.6`
  ├─▶ The build backend returned an error
  ╰─▶ Call to `setuptools.build_meta:__legacy__.build_wheel` failed (exit status:
      1)

      [stderr]
      /home/user/.cache/uv/builds-v0/.tmpsdhgNf/lib/python3.13/site-packages/setuptools/_distutils/dist.py:289:
      UserWarning: Unknown distribution option: 'tests_require'
        warnings.warn(msg)
      /home/user/.cache/uv/builds-v0/.tmpsdhgNf/lib/python3.13/site-packages/setuptools/_distutils/dist.py:289:
      UserWarning: Unknown distribution option: 'test_suite'
        warnings.warn(msg)
      error in blessings setup command: use_2to3 is invalid.

      hint: This usually indicates a problem with the package or the build
      environment.
  help: `blessings` (v1.6) was included because `maybe` (v0.4.0) depends on
        `blessings==1.6`

I've been mostly not using Python since it's arrival in the early 90s. Meaning I tinker with it but don't use it professionally.

Well, I hate Python. Main points for me: the scoping (or lack of it), the lack of declaration of new identifiers (linked to lack of scoping), the lack of update operators (like `a ||= (i > 0)`), the general lack of conciseness, the `a if b else c` confusion, the weirdness of comprehensions (particularly nested `for`s), the exceptions that are raised for non-exceptional cases. The heaviness of handling exception, like trying to delete a non-existing dict entry (need an additional `if` or a `try` block) or access a non-existing map entry (need to use `.get()` instead of `[]` or a `try` block).

Also, the syntax of layout is bad. I am not talking about layout itself, I do like Haskell syntax (despite being weird about parens). But if I write `a = b +` in Python on one line, then I get a syntax error, although the parser could instead assume that the expression is not terminated and must (obviously) continue on the next (indented) line. I hate that I need to use `\` or `(...)` to make this clear to the parser. I wrote parsers myself, and I know that it knows what needs to follow, and Python itself shows me that it knows: by raising a completely unnecessary syntax error.

It feels to me that the Python language design confuses `simple and easy` with `primitive`. If feels like a design without the knowledge of programming language research and ergonomy. It feels to me like a dangerous toy language, and I am never sure which of my stupid mistakes will be found by the compiler/interpreter, and which will just silently misinterpreted. And which of my perfectly valid requests will be rejected with an exception. In some aspects it feels less safe than C, particularly due to the lack of scoping and the danger of reuse of variables or introduction of new function local variables when actually, outer 'scope' variables were intended to be written.

This is not really meant as a rant, but it is a personal opinion, and I try to lay out my reasons. I am not trying to shame anyone who loves Python, but I just want to clarify that there are people who hate Python.

I hate python and I use it everyday because I work in the data space. Its a toy scripting / glue language that has gotten used for far too much that it was not designed for. The usual suspects are also really annoying, such as white space instead of {}, no types, its so damn slow and all projects use so many packages and the packages use packages etc. That last one could just be a personal preference thing to I will admit, but the rest are just almost objectively bad. Especially when building infrastructure like a data platform.

raises hand I hate python.

Every python codebase i’ve had to look after has rotten to the point it doesn’t even build and is a maintenance nightmare.

I also hate whitespace instead of {}

Than you would probably like the Nim[1] programming language. It has the syntax of python, but transpiles to C/C++. A good type system. The main problem would probably the compiles times. Because you basically compile just C/C++ code. And of course the eco-system is much much smaller than Python.

[1] https://nim-lang.org/

Rust doesn't quite hit all of those, but it hits a lot of them.

It's syntax is significantly different from python, but it does have operator overloading.

It's performance is comparable to go, and has good concurrency support, although it is different than go, and there are still some rough edges with "async" code. Compile times aren't as good as go though.

The type system is excellent, although I'm not really sure what you mean by "flexible".

And FFI support is great.

This looks exactly what I'm trying to do with SPy -- although SPy is still "not there" and it's WIP. I literally wrote an intro post about it yesterday: https://antocuni.eu/2025/10/29/inside-spy-part-1-motivations...

Kotlin on a modern JVM comes pretty close.

* Performance - the JVM is very competitive with C/C++ performance.

* Compile times - Not go fast, but not C/C++/Rust slow.

* Concurrency - Virtual threads (finalized in 21) bring in the concurrency capabilities of go to the JVM

* Type System Flexibility - Kotlin isn't quite as flexible as Typescript, but it's pretty close. It's more flexible than java but not as flexible as scala. I think it strikes a good middle ground.

* Native platform integration - This is probably the weakest part of the JVM but it's gotten a lot better with the work done on Project Panama (mostly delivered in 22). Jextract makes it a lot easier to make native integrations with Java. Definitely not as painful as the JNI days.

There's also kotlin native that you could play around with (I haven't).

Mojo is aiming at that. I've decided it's this years advent of code language for me and kinda looking forward to learning more about it.

I think Julia largely accomplishes these goals except for the platform integration.

I feel so much comfortable with Go's type system than Typescript's

Why would operator overloading be absolutely critical? Just use methods. The pipe operator already has around 15 uses and counting, it doesn’t need more

Also, case matching of Scala <3

You may be interested in Mojo, it's a project by Chris Lattner. It aims to have Python-like syntax and smooth integration with Python but allow Rust-like low-level control (I believe it has a borrow checker). Unfortunately, I believe it's proprietary.

Free Pascal with better tooling?

There's Mojo, but it's been a while since I've heard anything about it.

https://www.modular.com/mojo

There’s this thing where you work to requirements instead of picking things on vibes, it’s called engineering.

I understand the argument but the language used for uv (rust) and python don't have the same goal.

Python aims to be simple, not particularly fast (though it is getting faster)

I don't see a problem with that. Pick the language adapted to your problem. Python isn't aiming at solving every problem and that's okay.

Python performance is poor. Python achieves performance by having as little python code as possible. The runtime and all performant libraries are not in python.

It's ok for IO bound but not for CPU bound work.

Interpreted languages are not the best choicce for a variety of software. for eg: Vast amount of performance issues in typescript cli boil down to being written in typescript, and team is porting to golang now.

Tools specifically CLI tools, are best written in statically typed compiled languages.

And that's how languages start optimizing towards being a better language to write compilers in ;-)

It's completely fair for a language to have a niche different that 'quick start-up and runtime'.

Different tools for different use cases.

Would you write an assembler IDE in assembler?

I use Python for >90% of my code these days. I love uv for its ux and speed. I 0% care it wasn't written in Python. In fact, making it fully independent of any existing Python environment is a plus for the Python user. No weird bootstrap problems.

It does not make me switch to Rust for my own code.

Well Python Language should be seen as an UI layer for C++/C. Not out of character to use Rust for "heavy lifting"

That's like every language. The language you work in (typically) has all sorts of libraries that are lower level. And even if not it's not like you're code is 'running', it's compiling to lower level code that actually runs and the compilers that do that work are usually black box unless you're a compiler engineer.

The power of Python is that it's high level and very powerful and has a great community and ecosystem of tools/libraries. There's absolutely zero problem and totally a good thing if there are core libraries written in faster languages.

In a similar vein, Microsoft TypeScript team picked Go for the new TypeScript transpiler engine.

Bash is written in what?

the python interpreter is not written in python :-)

The “Faster CPython” team were let go from Microsoft because they could only produce a 1.5x speedup in four years instead of the planned 5x.

It’s wildly optimistic to now expect a 10x speedup in two years, with fewer resources.

I'd be surprised if we saw anything more than the 4x speedup from compiling Python with something like Nuitka/mypyc/etc can bring.

I also believe the JIT in v8 and Python are different, the latter relying on copy-and-patch while v8 uses a bunch of different techniques together.

I would surprised to see performance as good as V8, although that would be great. As I recall the v8 team performed exceptionally well in a corporate environment that badly wanted js performance to improve, and maybe inherited some Hotspot people at the right time.

I'd be quite delighted to see, say, 2x Python performance vs. 3.12. The JIT work has potential, but thus far little has come of it, but in fairness it's still the early days for the JIT. The funding is tiny compared to V8. I'm surprised someone at Google, OpenAI et al isn't sending a little more money that way. Talk about shared infrastructure!

pypy is probably faster. Lets put effort into that. BUT the dynamic features that make python lovely are always going to limit its performance.

If you're using python because you have to then you might not like all that and might see it as something to toss out. This makes me sad.

It didn't "remove the GIL". It added an experimental free-threading mode which removes it, but is still considered experimental and not widely used in production yet.

Has something changed that allows a more relaxed refcounting / less eager "gc"? Py_DECREF was what murdered any hope of performance back when we hooked up 3.3 to OMR... Well that and the complete opacity of everything implemented in C

I bet we’ll be seeing python compiled to JVM of getting JVM levels of performance. Much better than v8

What is the distinction between "package manager and install manager"?

How do extra bells and whistles bother you? You had the option to not use them. Like you said yourself, they’re “extra”.

I think in Python specifically, an install manager is absolutely the right call. There's far too much breakage between Python versions.

I recently had to downgrade one of our projects to 3.12 because of a dependency we needed. With uv, I can be sure that everybody will be running the project on 3.12, it just all happens automatically. Without uv, I'd get the inevitable "but your changes crashed the code, have you even tested them?"

Honestly I think poetry was a bigger development than uv. I used pipenv before it, and requirements before that, and I can't imagine going back. I've yet to fully embrace uv and migrate away from poetry for that reason (even thought it seems inevitable at this point, there's just no need)

I write Python all day for work and I run into its issues all the time, be it performance or weak typing or just lack of modern language features. If you’re just vibecoding all day and that’s ok for what you want it to do, all the more power to you, but do at least take a moment to understand that when people want things you see no value in maybe they just have different requirements than you do.

The irony here is UV is written in Rust.

Python is bad for large projects, and it's not just because of speed.

I see it shine for scripts and AI but that's it.

>$1000 per month is considered expensive as hell for an EC2 instance, but no developer would work for $12000 a year.

If using Python instead of what we use, our cloud costs would be more than double.

And I can't go to CEO and CFO and explain to them that I want to double the cloud costs (which are already seen as high).

Then, our development speed won't really improve because we have large projects.

That being said, I think using Python for scripting is great in our case.

Nice essat bro. what's your real world experience scaling a python service, and how many DB-backed or computationally otherwise non trivial (select one entry by ID doesn't count) requests does it handle? We want to listen to your hard earned practical wisdom.

And a shell

This is a PEP and not specific to uv: https://peps.python.org/pep-0723/

Is that a dare? /s

Small price to pay for escaping python dependency hell.

> As long as your

linux core utils have supported this since 2018 (coreutils 8.3), amusingly it is the same release that added `cp --reflink`. AFAIK I know you have to opt out by having `POSIX_CORRECT=1` or `POSIX_ME_HARDER=1` or `--pedantic` set in your environment. [1]

freebsd core utils have supported this since 2008

MacOS has basically always supported this.

---

1. Amusingly despite `POSIX_ME_HARDER` not being official a alrge swapt of core utils support it. https://www.gnu.org/prep/standards/html_node/Non_002dGNU-Sta...

If you’re executing a script from an untrusted source, you should be examining it anyway. If it fails to execute because you haven’t installed the correct dependencies, that’s an inconvenience, not a lucky security benefit. You can write a reverse shell in Python with no dependencies and just a few lines of code.

You’re about to run an untrusted python script. The script can do whatever it wants to your system. Dependencies are the least of your worries.

If that’s your concern you should be auditing the script and the dependencies anyway, whether they’re in a lock file or in the script. It’s just as easy to put malicious stuff in a requirements.txt

Would you feel better with a script containing eval(requests.get(“http://pypi.org/foo.py”)) ?

It’s the script contents that count, not just dependencies.

Deno-style dependency version pinning doesn’t solve this problem unless you check every hash.

I didn't see it in the comments, but FWIW you can choose specific dependencies. You can use regular [dependency specifiers](https://packaging.python.org/en/latest/specifications/depend...), see [PEP 723](https://packaging.python.org/en/latest/specifications/inline...).

Is there anything new that uv gives you here though?

If you don't care about being ecosystem-compliant (and I am sure malware does not), it's only a few lines of Python to download the code and eval it.

""" uv is straightforward to install. There are a few ways, but the easiest (in my opinion) is this one-liner command — for Linux and Mac, it’s:

curl -LsSf https://astral.sh/uv/install.sh | sh """

Also isn't great. But that's how homebrew is installed, so ... shrug ... ?

Not to bash uv/homebrew, they are better than most _easy_ alternatives.

uv can still be redirected to private PyPi mirror, which should be mandatory from security and reliability perspective anyway.

Thats the same thing?

> Based on the man page it doesn’t appear to be doing anything useful here

The man page tells me:

  -S, --split-string=S
         process and split S into separate arguments; used to pass multi‐
         ple arguments on shebang lines

See also: https://unix.stackexchange.com/questions/361794

Without -S, `uv run --script` would be treated as a binary name (including spaces) and you will get an error like "env: ‘uv run --script’: No such file or directory".

-S causes the string to be split on spaces and so the arguments are passed correctly.

I wouldn't be surprised if astral's next product would be something like this. It's so obvious and there would be much interest from the ML crowd.

My current hobby language is janet. Creating a statically linked binary from a script in janet is trivial. You can even bring your own C libraries.

Zipapp comes close: https://docs.python.org/3/library/zipapp.html

Have you tried Nuitka? It takes a little effort but it can compile your Python program to a single executable that runs without network access.

And electricity and running water and oh the inconvenience. How is this worse than getting a script file that expects you to install modules?

If I download python project from someone on the same network as me and they have it written in a different python version to me and a requirements.txt I need all those things anyway.

You can constrain Python version: https://peps.python.org/pep-0723/#:~:text=requires-python

I mean, if you use == constraints instead of >= you can avoid getting different versions, and if you’ve used it (or other things which combined have a superset of the requirements) you might have everything locally in your uv cache, too.

But, yes, python scripts with in-script dependencies plus uv to run them doesn't change dependency distribution, just streamlines use compared to manual setup of a venv per script.

You can specify python version requirements in the comment, as the standard describes

Never underestimate cultural momentum I guess. NBA players shot long 2 pointers for decades before people realized 3 > 2. Doctors refused to wash their hands before doing procedures. There’s so many things that seem obvious in retrospect but took a long time to become accepted

So many times I have come onto a library or tool that would fix my problem, and then realized “oh crap, it’s in Python, I don’t want to spend few hours building a brittle environment for it only for that env to break next time I need to use it” - and went to look for a worse solution in better language.

I agree with you wholeheartedly, besides not preferring dynamic programming languages, I would in the past have given python more of a look because of its low barrier to entry...but I have been repulsed by how horrific the development ux story has been and how incredibly painful it is to then distribute the code in a portable ish way.

UV is making me give python a chance for the first time since 2015s renpy project I did for fun.

That's because many people don't pay attention to reproducibility of their developed software. If there is no lock file in a repo that nails the exact versions and checksums, then I already know it's likely gonna be a pain. That's shoddy work of course, but that doesn't stop people from not paying attention to reproducibility.

One could argue, that this is one difference between npm and such, and what many people use in the Python ecosystem. npm and cargo and so on are automatically creating lock files. Even people, who don't understand why that is important, might commit them to their repositories, while in the Python ecosystem people who don't understand it, think that committing a requirements.txt only (without checksums) is OK.

However, it is wrong, to claim, that in the Python ecosystem we didn't have the tools to do it right. We did have them, and that well before uv. It took a more care though, which is apparently too much for many people already.

You aren’t kidding. Especially if it’s some bioinformatics software that is just hanging out there on GitHub older than a year…

The only thing I dreaded more was trying to run other people's C++ projects.

I used to think this sentiment was exaggerated. Then I tried installing Dots OCR. What a nightmare, especially when NVIDIA drivers are involved.

I was into Python enough that I put it into my username but this is also my experience. I have had quasi-nightmares about just the bog of installing a Python project.

Same! And Python was my first, and is currently my second-highest-skill language. If someone's software's installation involves Python, I move on without trying. It used to be that it would require a Python 2 interpreter.

Honorable mention: Compiling someone else's C code. Come on; C compiles to a binary; don't make the user compile.

I dread running my own Python projects if I haven't worked with them in a while.

How about shipping one? Like even just shipping some tools to internal users is a pain

Couldn't agree more. I have a project at work from 2016 that builds multiple different HMIs (C++) along with 2 embedded systems (C). They all have to play nicely with each other as they share some structures and can all be updated in the field with a single file on a USB stick. So there is a bash script that builds everything from a fresh clone, makes update files, and some other niceties. Then, there is a single python script that generates a handful of tables from a json file.

Guess which part of the build I spent fixing the other day... It wasn't the ~200000 lines of c/c++ or the 1000+ line bash script. No. It was 100 lines of python that was last touched 2 years years ago. Python really doesn't work as a scripting language.

The python community was in profound denial for a very long time.

Not even trying to compile build other people's C/C++ projects on *nix?

I really don't understand this. I find it really easy.

pfff... "other people projects".. I was not even able to run my own projects until I started using Conda.

Just stick to what's in your linux distribution and you've got no problems.

That works for simple cases. Now, update a transitive dependency used by more than one dependency. You might get lucky and it'll just work.

That works, more or less. But now you have a requirements.txt file with 300 dependencies. Which ones do you actually care about, and which are just transitive things that your top-level deps brought along for the ride? And a year later, when GitHub's Dependabot is telling you have a security vulnerability in some package you've never heard of, do you remember if you even care about that package in the first place, or if it's left over cruft from that time you experimented with aiohttp instead of httpx?

As a “pip is mostly fine” person, we would direct the result to a new lock file, so you could still have your direct does and then pin transitives and update

Pips solver could still cause problems in general on changes.

UV having a better solver is nice. Being fast is also nice. Mainly tho it feeling like it is a tool that is maintained and can be improved upon without ripping one’s hair out is a godsend.

This is way less than what uv and other package managers do:

- dev dependencies (or other groups) - distinguishing between direct and indirect dependencies (useful if you want to cut some fat from a project) - dependencies with optional extra dependencies (if you remove the main, it will delete the orphans when relevant)

It's not unachievable with pip and virtualenvs, but verbose and prone to human error.

Like C: if you're careful enough, it can be memory safe. But teams would rather rely on memory safe languages.

It is also manages the runtime, so you can pin a specific runtime to a project. It is very useful and worth investigating.

I am on the same boat. I like uv for its speed and other niceties it brings and being a single tool to manage different things. But lockfile is not that big a deal. I never got Poetry as well. Tried it in a project once and the lockfile was a pain with the merges. I didn’t spend much time, so maybe I didn’t understand the tool and workflow or whatever, but pip and pip-tools were just fine working with requirements.txt.

The canonical way to do this with pip was using Constraints Files [1]. When you pollute your main requirements.txt it gets harder to see which package is an actual dependency of your project, and which ones are just sub-dependencies. Constraint files also let you not install a package if it's no longer a sub-dependency.

That being said, the uv experience is much nicer (also insanely fast).

[1] https://pip.pypa.io/en/stable/user_guide/#constraints-files

Honestly, this feels like the difference between Cmake and cargo, sure Cmake does work and you can get to do everything you need, you just need discipline, knowledge and patience. On the other hand, you could just have a tool that does it all for you so you can get back to doing the actual work.

I don’t get the hype either. Every time I’ve tried to use tools like pyenv or pipenv they fall down when I try to install anything that doesn’t provide wheels (GDAL), so I give up and stick to pip and virtualenv. Does uv let me install GDAL without hassle?

I've never even understood the virtual env dogma. I can see how version conflicts _could_ happen, but they never have. Admittedly, I'm surprised I never have issues installing globally, especially since others keep telling me what a terrible idea it is and how they had nightmare-scenario-X happen to them.

It is indeed fairly simple to implement it, which is why it's so weird that it's never been implemented at a language level

Oops, you forgot to sh into you venv and now your env is messed up.

Good luck if you need cross-platform `requirements.txt` files.

I've gone all-in on Bun for many of the same reasons. Blazingly fast installs too.

https://bun.sh/

Deno is pretty sweet too... shell scripts that don't need a package.json or a node_modules directory for dependencies.

I find pnpm annoying to type, that's why I don't use it

npm has evolved, slowly, but evolved, thanks to yarn and pnpm.

It even has some (I feel somewhat rudimentary) support for workspaces and isolated installs (what pnpm does)

Lock files are only needed because of version ranging.

Maven worked fine without semantic versioning and lock files.

Edit: Changed "semantic versioning" to "version ranging"

I used poetry professionally for a couple of years and hit so many bugs, it was definitely not a smooth experience. Granted that was probably 3-4 years ago.

There was pipenv before that too, which also had a lockfile.

Funny how these things get forgotten to history. There's lots of prior art when it comes to replacing pip.

edit: here's an HN thread about pipenv, where many say the same things about it as they are about UV and Poetry before https://news.ycombinator.com/item?id=16302570

and pip-compile before that.

Agree that uv is way way way faster than any of that and really just a joy to use in the simplicity

I have to agree that there were a lot of good options, but uv's speed is what sets it apart.

Also the ability to have a single script with deps using TOML in the headers super eaisly.

Also Also the ability to use a random python tool in effectively seconds with no faffing about.

you mean you can't just do `venv/bin/python --version`?

It's not fixed quite yet because the default recommended way is still pip. And that's the same reason past attempts didn't work.

It didn't, though? Poetry was largely fine, it's just that uv is so much faster. I don't think uv is that much different from Poetry in the day-to-day dependency management, I'm sure there are some slight differences, but Poetry also brought all the modern stuff we expected out of a package manager.

Imo the community should've rejected Python 3 and said, find a way to improve things without breaking everyone. JS managed to do it.

Yeah I use poetry, uv and requirements.txt - all great tools for their respective niches.

Yep, coming from poetry, uv is a pure speed increase with the same feature set.

Hackernews and also the official Python maintainers

cargo is better than npm, yes, but npm is better than pip (in my experience)

Both of these work

> But you are just using virtualenv with pip.

No, you aren't.

> It doesn't change any of the moving pieces

It literally does, though iyt maintains a mostly-parallel low-level interface, the implementation is replaced with improved (in speed, in dependency solving, and in other areas.) You are using virtual environments (but not venv/virtualenv) and the same sources that pip uses (but not pip).

> You've been able to have the exact same setup forever with pyenv and pyenv-virtualenv except with these nothing ever has to be prefixed.

Yes, you can do a subset of what uv does with those without prefixes, and if you add pipx and hatch (though with hatch you’ll be prefixing for much the same reason as in uv) you’ll get closer to uv’s functionality.

> Look, uv is amazing and I would recommend it over everything else but Python devs have had this flow forever.

If you ignore the parts of the flow built around modern Python packaging standards like pyproject.toml, sure, pieces of the flow have been around and supported by the right constellation of other standard and nonstandard tools for a while.

conda ruined my shell and never successfully worked for me. I guess YMMV

same here; I now prefer uv but conda served us very well, and allowed us to maintain stable reproducible environments; being able to have multiple environments for a given project is also sometimes handy vs a single pyproject.toml

miniconda

Unless all python dependencies you ever used were available in your distro (and then at that point, you're no longer using pip, you're using dpkg...), this never worked well. What solves this well is PEP 723 and tooling around it.

With PEP 723 and confortable tooling (like uv), now you get scripts, that are "actually directly runnable", not just "fake directly runnable oops forgot to apt-get install something sorta runnable", and work reliably even when stuff around you is updated.

> You used to be able to avoid virtualenvs and install scripts and dependencies directly runnable from any shell.

This wasn't really the case; in principle anything you installed in the system Python environment, even "at user level", had the potential to pollute that environment and thus interfere with system tools written in Python. And if you did install it at system level, that became files within the environment your system package manager is managing, that it doesn't know how to deal with, because they didn't come from a system package.

But it's worse now because of how many system tools are written in Python — i.e., a mark of Python's success.

Notably, these tools commonly include the system package manager itself. Since you mentioned Debian (actually this is Mint, but ya know):

  $ file `which apt`
  /usr/local/bin/apt: Python script, ASCII text executable

No, you don't. Nothing prevents you from running scripts with the system Python that make use of system-provided libraries (including ones that you install later with the system package manager).

If you need something that isn't packaged by your distro, then of course you shouldn't expect your distro to be able to help with it, and of course you should expect to use an environment isolated from the distro's environment. In Python, virtual environments are the method of isolation. All reasonable tooling uses them, including uv.

> Debian was a bastion of sanity with the split between dist_packages and site_packages but that's ruined now too.

It's not "ruined". If you choose to install the system package for pip and to use it with --break-system-packages, the consequences are on you, but you get the legacy behaviour back. And the system packages still put files separately in dist-packages. It's just that... doing this doesn't actually solve all the problems, fundamentally because of how the Python import system works.

> Python as a general purpose utility

This ideology is what caused all the problems to begin with, the base python is built as if it's the only thing in the entire operating systems environment when it's entire packaging system is also built in a way that makes that impossible to do without manually having to juggle package conflicts/incompatibilities.

This is very true! I was highly surprised when I installed Python from source and found out, that the entire problem is fixed since decades. You can have different Python versions in the same prefix just fine, you just need to pick a default one you install with `make install` and install all the others with `make altinstall`.

it's because so many essential system tools now rely on python, and if you install arbitrary code outside of a venv it can clobber the global namespace and break the core OS' guarantees.

I do agree it is annoying, and what they need to do is just provide an automatic "userspace" virtualenv for anything a user installs themselves... but that is a pandoras box tbh. (Do you do it per user? How does the user become aware of this?)

I followed much of this path as well, but with conda (and mamba) in the mix. They all had fairly obvious flaws that uv doesn’t AFAICT.

Poetry was the worst for me. It doesn’t even try to manage the Python distribution, so it’s only a partial solution. It was so slow our CICD would timeout and fail. And I watched the maintainers actively refuse to fix super annoying bugs for YEARS, blaming others for the problem.

It certainly isn't. See here: https://github.com/astral-sh/uv/issues/5190

And here: https://pyproject-nix.github.io/uv2nix/FAQ.html#why-doesnt-u...

That doesn't really seem like a way to avoid getting "Broadcommed." Vertically integrated tooling is kind of a commodity.

hmm how well did that work for Docker ...

It doesn't seem to answer to anything.

npm runs dog slow IME

Things uv does better by pip by default: - really hard to install a package globally by accident (pip: forgetting to activate venv) - really easy to distinguish de and main dependencies (pip: create different files for different groups and set up their relationship) - distinguish direct dependencies from indirect dependencies, making it easy to find when a package is not needed anymore (pip: I bet most devs are either not tracking sub dependencies or mixing all together with pip freeze) - easily use different python versions for different projects (pip: not really)

With uv it just works. With pip, technically you can make it work, and I bet you'll screw something up along the way.

For sure, we see the same thing in the JS ecosystem. New tooling adds some feature, other options implement feature, convergence to a larger common set.

I'm still mostly on poetry

The things you list may be a reason for some, but in all discussions I’ve had and read about on uv, the reason is that it behaves as a package manger should. It can just install dependencies from an automatically generated lockfile. It can update outdated minor versions. It can tell me about outdated versions of my dependencies. It can reproduce a build on another machine. The lock file can be put into version control. A coworker can run a single command to install everything. It abstracts the stupidity that is virtual environments away so much you don’t even have to touch them anymore. And also, it’s fast.

Wake me up when pip can do any of that.

> Seems like everything that would benefit from it is already written in highly optimized native modules

Or by asyncio.

I second and third this. I HATE python but uv was what made it usable to me. No other language had such a confusing obnoxious setup to do anything with outside of js land. uv made it sane for me.

But there has been continual improvement over that time, both in the ecosystem, and in the language (like a syntax for generics).

And yet you still cannot write even moderately complex type expressions without severe pain.

You can get pretty darn close to static typing by using ty (from the same team as uv).

I've been using it professionally and its been a big improvement for code quality.

If you've ever used python on a project above a certain size (both lines of code and people who contribute to it), type annotations quickly become something you find useful.

You can disable it, here's the PEP, search has more digestible options

https://peps.python.org/pep-0703/

I think OP's complaint is rather that using `uv` is leaky: now you need to learn all the underlying stuff AND uv as well.

The alternative, of course, is having Python natively support a combined tool. Which you can support while also not liking `uv` for the above reason.

Yeah, I agree. In particular it seems insane to me that virtualenv should have to exist. I can't see any valid use case for a machine-global pool of dependencies. Why would anyone think it should be a separate tool rather than just the obvious thing that a dependency manager does? I say this as someone with nearly 20 years of Python experience.

It's the same sort of deal with pyenv--the Python version is itself a dependency of most libraries, so it's a little silly to have a dependency manager that only manages some dependencies.

Python versions and environments can be solved in more reliable abstraction level as well, e.g. if you are heavy Nix user.

"other languages don't have 3 different tools for this." But other languages DO have 3 different tools so we should do that too!

There is an optional & experimental code formatting tool within uv (that just downloads riff), which is what OP may be referring to: https://pydevtools.com/blog/uv-format-code-formatting-comes-...

> I had been hoping someone would introduce the non-virtualenv package management solution that every single other language has where there's a dependency list and version requirements (including of the language itself) in a manifest file (go.mod, package.json, etc) and everything happens in the context of that directory alone without shell shenanigans.

Isn't that exactly a pyproject.toml via the the uv add/sync/run interface? What is that missing that you need?

What are you needing to use `uv pip` for? I don't think I ever call into pip from uv for anything nowadays. I typically just need to do `uv sync` and `uv run`, maybe sometimes `uvx` if I want to run some random 3rd party python script

> I had been hoping someone would introduce the non-virtualenv package management solution that every single other language has where there's a dependency list and version requirements (including of the language itself) in a manifest file (go.mod, package.json, etc) and everything happens in the context of that directory alone without shell shenanigans.

If you are using uv, you don’t need to do shell shenanigans, you just use uv run. So I'm not sure how uv with pyproject.toml doesn't meet this description (yes, the venv is still there, it is used exactly as you describe.)

In most cases, you don't really need to manage virtual envs though ? uv commands that need a venv will just create one for you or install to the existing one automatically.

Pixi is an alternative that you may want to try.

Really sounds like you're using it wrong, no? I completely forgot about virtualenvs, pip and requirements.txt since I start using UV.

What doesn’t just work about uv in particular? You basically need three commands - uv add, uv sync, and uv run. Forget about virtual environments, and get back to working. No configuration necessary.

Slow doesn't really begin to do justice, I'd have to wait for >5 minutes for pipenv to finish figuring out our lock file. uv does it in less than a second.

> Pipenv is just straightforward and “just works”

I have worked on numerous projects that started with pipenv and it has never "just works" ever. Either there's some trivial dependency conflict that it can't resolve or it's slow as molasses or something or the other. pipenv has been horrible to use. I started switching projects to pip-tools and now I recommend using uv

What's your use case for UV_NO_SYNC? I assume the option exists for a reason, but aside from maybe a modest performance improvement when working with a massive complex package environment, I'm not sure what problem it solves.

Yes, you still have the option of manually activating a venv, and that makes sense if the amortized cost of that is lower than several instances of typing `uv run `. Though sometimes when working in one project with its venv activated, I end up needing to run a tool from another project with a separate vent, so uv still ends up being useful.

that makes me feel much better!

it's not really the number of characters so much as the cognitive load of having to do something different here vs there and anything I run successfully on the command line can't be directly lifted over into scripts etc. Along with training a team of people to do that.

I typically type py<TAB>.

> What does uv do in order to resolve dependencies much faster?

- Representing version numbers as single integer for fast comparison.

- Being implemented in rust rather than Python (compared to Poetry)

- Parallel downloads

- Caching individual files rather than zipped wheel, so installation is just hard-linking files, zero copy (on unix at least). Also makes it very storage efficient.

> The article shows some advantages compared to plain virtual environments

No; they are plain virtual environments. There is no special kind of virtual environment. Uv simply offers its own command structure for managing those environments. In particular, `uv run` just ensures a venv in a specific location, then uses it.

There is no requirement to activate virtual environments in order to use them (unless you have some other tooling that specifically depends on the environment variables being set). You can, similarly, "just do"

  .venv/bin/python myscript.py

> This command automatically picks up the correct virtual environment for you

Some people dislike such magic, especially since it involves uv having an opinion about where the virtual environment is located.

> Pypa does not make good stuff or make good decisions.

yep, I've been saying this for years, and astral have proved it in the best way: with brilliant, working software

python was a dying project 10 years ago, after the python 3000 debacle

the talent left/lost interest

then the machine learning thing kicked off (for some reason using python), and now python is everywhere and suddenly massively important

and the supporting bureaucracies, still in their death throes, are unable to handle a project of its importance

It's still annoying to fork and they will probably try to move it to their own pypi service so it won't be possible to do that.

You updated _production_ before _testing_? Sorry but that just sounds like asking for a disaster.

Package managers or old school download from a website (gnu) provide a separate public checksum and GPG signature in multiple mirrored locations. Even if their server was compromised I can still be safe.

If you look at the script, this is indeed more or less what happens. Except the folks over there are very clever about ergonomics, so the script is quite long so it can detect your architecture, OS, and even libc to give you an appropriate binary. There’s a tool that they use (which they wrote) which generates such install scripts for you

It’s really excellent stuff

but since you are curling a web URL straight to sh you will never know. which is the problem.

Or, you can use a task runner like mise or just, and tell it to use the task runner instead of any particular tool directly. `mise test:unit` is much harder for an agent to get wrong.

You don't have to modify the environment (this is provided as an option for convenience). The alternatives are to use higher-level management like uv does, or to specify the path to executables in the virtual environment directly. But uv works by creating virtual environments that are essentially the same as what you get with `python -m venv --without-pip` (although they reimplemented the venv creation logic).

Pip can install from dependency groups in a pyproject.toml file, and can write PEP 751 lockfiles, and work is under way to allow it to install from those lockfiles as well.

I don't know what you mean about a "standard dependency dir". When you make a venv yourself, you can call it what you want, and put it where you want. If you want to put it in a "standard" place, you can trivially make a shell alias to do so. (You can also trivially make a shell alias for "activate the venv at a hard-coded relative path", and use that from your project root.)

Yes, pip installation is needlessly slow for a variety of reasons (that mostly do not have to do with being implemented in Python rather than Rust). Resolving dependencies is also slow (and Rust may be more relevant here; I haven't done detailed testing). But your download speed is still going to be primarily limited by your internet connection to PyPI.

As of half a year ago with pip 25.1, it can install from "dependency groups" listed in pyproject.toml: https://ichard26.github.io/blog/2025/04/whats-new-in-pip-25....

Pip also generates PEP 751 lockfiles, and installing from those is on the roadmap still (https://github.com/pypa/pip/issues/13334).

venv is lower-level tooling. Literally all it does is create a virtual environment — the same kind that uv creates and manages. There's nothing to "integrate".

A package is at least a signable, checksummable artefact. The curl | sh thing could have been anything and after running it you have no record of what it was you did.

There have also been PoCs on serving malicious content only when piped to sh rather than saved to file.

If you want to execute shell code from the internet, at the very least store it in a file first and store that file somewhere persistent before executing it. It will make forensics easier

Security and auditability is not the core problem, it's versioning and uninstalling. https://docs.sweeting.me/s/against-curl-sh

That is still checked for its signature, the only thing you bypass is the automatic download over HTTP and dependency resolution by default.

For small project open source with a CLI audience, why bother with an install script at all and not just provide tarballs/ZIP files and assume that the CLI audience is smart enough to untarball/unzip it to somewhere on their PATH?

Also, many of the "distribution" tools like brew, scoop, winget, and more are just "PR a YAML file with your zip file URL, name of your EXE to add to a PATH, and a checksum hash of the zip to this git repository". We're about at a minimum effort needed to generate a "distribution" point in software history, so seems interesting shell scripts to install things seem to have picked up instead.

> Maybe if you trust the software, then trusting the install script isn't that big of a stretch?

The software is not written in a scripting language where forgetting quote marks regularly causes silent `rm -rf /` incidents. And even then, I probably don't explicitly point the software at my system root/home and tell it to go wild.

Part of writing software involves writing a way to deploy that software to a computer. Piping a web URL to a bash interpreter is not good enough. if that's the best installer you can do the rest of your code is probably trash.

A malicious server could detect whether the user is actually running "curl | sh" instead of just "curl" and only serve a malicious shell script when the code is executed blindly. See this thread for reference: https://news.ycombinator.com/item?id=17636032

That doesn't fix the core issue. You can put anything inside a .deb file, even preinstall script can send your ~/.aws/credentials to China. The core concern is getting a package that's verified by a volunteer human to not contain anything malicious, and then getting that package into Debian repository or equivalent.

As someone that is fine on poetry for a few things, is there a good pitch deck on why I should change over?

Managing environments with `python -m venv` and all of the easy ways that goes wrong is exactly what I don't want to deal with. Is almost enough to make me never want to use python.

What they say today and what will the board decide to do in 6 months are 2 entirely separate things.