[skeledrew]

I'm generally not a fan of the incremental rustification of the Python ecosystem, but I started using uv a few weeks ago just for this particular case and have been liking it. And to the point where I'm considering to migrate my full projects as well from their current conda+poetry flow. Just a couple days ago I also modified a script I've been using for a few years to patch pylsp so it can now see uv script envs using the "uv sync --dry-run --script <path>" hack.

[ratorx]

Out of curiosity, what are some problems with rustification? Is it an aversion to Rust specifically or a dislike of the ecosystem tools not being written in Python?

The former is subjective, but the latter seems like not really much of an issue compared to the language itself being written in C.

[zahlman]

Speaking for myself:

I have no aversion to Rust (I've read some of it, and while foreign, it comes across as much more pleasant than C or C++), but the way it's promoted often is grating. I'm getting really tired in particular of how the speed of Rust is universally described as "blazing", and how "written in Rust" has a sparkle emoji as mandatory punctuation. But maybe that's just because I'm, well, older than Python itself.

I don't really care that the reference implementation isn't self-hosting (although it's nice that PyPy exists). Using non-Python for support (other than IDEs - I don't care about those and don't see a need to make more of them at all) is a bit grating in that it suggests a lack of confidence in the language.

But much more importantly, when people praise uv, they seem to attribute everything they like about it to either a) the fact that it's written in Rust or b) the fact that it's not written in Python, and in a lot of cases it just doesn't stand up to scrutiny.

uv in particular is just being compared to a low bar. Consider: `pip install` without specifying a package to install (which will just report an error that you need to specify a package) on my machine takes almost half a second to complete. (And an additional .2 seconds with `--python`.) In the process, it imports more than 500 modules. Seriously. (On Linux you can test it yourself by hacking the wrapper script. You'll have to split the main() call onto a separate line to check in between that and sys.exit().)

[skeledrew]

It's more the latter, particularly when Rust is used in libraries (eg. FastAPI) as opposed to tools, as it's destroying portability. For example I use flet[0] in some of my projects, and I have to be increasingly careful about the other dependencies as there is no support for the Rust toolchain within Dart/Flutter, and even if there was it still sounds like it'd be a nightmare to maintain. Same applies to any other platforms/apps out there that support running Python for flexibility, and handling another language is just way out of scope (and I'm pretty sure there are quite a few). A key part of Python's existence is as glue between disparate system parts, and rustification is reducing it's usefulness for an increasing number of niche cases where it once excelled.

[0] https://flet.dev

[NeutralForest]

I can understand the sentiment somewhat. It's another layer of complexity and it makes working on projects more difficult. The fact pip or mypy code is all Python makes it much easier to interact with and patch if needed.

You can also write Cython for more perf oriented code but I can totally understand the value Rust brings to the table, it's just now another language you'll need to know or learn, more layers like maturin or pyO3, while cffi is just there.

All the tooling coming from astral is amazing and I use it everyday but I can see the increasing complexity of our toolchains, not in ergonomics (it's much better now) but the tools themselves.

[biorach]

> he fact pip or mypy code is all Python makes it much easier to interact with and patch if needed

But how often in your career have you actually done this?

[mvieira38]

Agree, this only seems like a problem for the vast minority that are developing developer tools. And, to be honest, they got themselves in this situation due to a skill issue, too, Astral is just stomping the existing tools with better ergonomics and speed.

[NeutralForest]

I'm not doing that but I'm not developing developer tooling either. I can go read mypy code though!

[biorach]

You can read uv code too. Rust isn't that hard to read a lot of the time

[skeledrew]

I haven't done much patching myself, but I've done it enough times to really appreciate having the capability when I do want to do it. It's one of the reasons why I have a huge preference for Python: its flexibility.

[zahlman]

I've been doing it recently as part of diagnosing Pip's performance issues.

[WesolyKubeczek]

A problem with rustification is that it puts a giant ecosystem on a giant ecosystem, with poorly matched tooling. C has a lot of home ground advantage, and CPytjon is built on it.

Then you have PyPy which you’d have to accommodate somehow.

It doesn’t help that in a case where you have to build everything, Rust build toolchain currently needs Python. That sure would make bootstrapping a bitch if Python and Rust became a circular dependency of one another.

[masklinn]

> Then you have PyPy which you’d have to accommodate somehow.

Adding pypy support to a pyo3 + maturin project was literally just a matter of telling maturin to build that wheel. And I added graal while at it.

Hopefully they eventually add stable ABI support too so I don’t have to add individual pypy/graal wheel targets.

Or pyo3 and maturin may support hpy once that’s stable.

[htunnicliff]

    I also modified a script I've been using for a few years to patch pylsp so it can now see uv script envs using the "uv sync --dry-run --script <path>" hack.

This sounds like a really useful modification to the LSP for Python. Would you be willing to share more about how you patched it and how you use it in an IDE?

[skeledrew]

I have a somewhat particular setup where I use conda to manage my envs, and autoenv[0] to ensure the env for a given project is active once I'm in the folder structure. So there's a .env file containing "conda activate <env_name>" in each. I also use Emacs as my sole IDE, but there are quite a few instances where support falls short for modern workflows. I use the pylsp language server, and it's only able to provide completions, etc for native libraries, since by default it doesn't know how to find the envs containing extra 3p packages.

And so I wrote a patcher[1] that searches the project folder and parents until it finds an appropriate .env file, and uses it to resolve the path to the project's env. With the latest changes to the patcher it now uses the output from "uv sync", which is the path to a standalone script's env, as well as the traditional "source venv_path/bin/activate" pattern to resolve envs for uv-managed projects.

[0] https://github.com/hyperupcall/autoenv [1] https://gitlab.com/-/snippets/2279333

[oulipo]

what's the --dry-run hack ?

[skeledrew]

Using "--dry-run" makes the command a no-op, but still prints the env path.