this post was submitted on 06 Nov 2024
184 points (98.4% liked)

Programming

17669 readers
221 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities [email protected]



founded 2 years ago
MODERATORS
 

So I'm no expert, but I have been a hobbyist C and Rust dev for a while now, and I've installed tons of programs from GitHub and whatnot that required manual compilation or other hoops to jump through, but I am constantly befuddled installing python apps. They seem to always need a very specific (often outdated) version of python, require a bunch of venv nonsense, googling gives tons of outdated info that no longer works, and generally seem incredibly not portable. As someone who doesn't work in python, it seems more obtuse than any other language's ecosystem. Why is it like this?

you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 3 points 1 month ago* (last edited 1 month ago) (1 children)

I moved all our projects (and devs) from poetry to uv. Reasons were poetry's non standard pyproject.toml syntax and speed, plus some weird quirks, e. g. if poetry asks for input and is not run with the verbose flag, devs often don't notice and believe it is stuck (even though it's in the default project README).

Personally, I update uv on my local machine as soon as a new release is available so I can track any breaking changes. Couple of months in, I can say there were some hiccups in the beginning, but currently, it's smooth sailing, and the speed gain really affects productivity as well, mostly due to being able to not break away from a mental "flow" state while staring at updates, becoming suspicious something might be wrong. Don't get me wrong, apart from the custom syntax (poetry partially predates the pyproject PEP), poetry worked great for us for years, but uv feels nicer.

Recently, "uv build" was introduced, which simplified things. I wish there was an command to update the lock file while also updating the dependency specs in the project file. I ran some command today and by accident discovered that custom dependency groups (apart from e. g. "dev") have made it to uv, too.

"uv pip" does some things differently, in particular when resolving packages (it's possible to switch to pip's behavior now), but I do agree with the decisions, in particular the changes to prevent "dependency confusion" attacks.

As for the original question: Python really has a bit of a history of project management and build tools, I do feel however that the community and maintainers are finally getting somewhere.

cargo is a bit of an "unfair" comparison since its development happened much more aligned with Rust and its whole ecosystem and not as an afterthought by third party developers, but I agree: cargo is definitely a great benchmark how project and dependency management plus building should look like, along with rustup, it really makes the developer experience quite pleasant.

The need for virtual environments exists so that different projects can use different versions of dependencies and those dependencies can be installed in a project specific location vs a global, system location. Since Python is interpreted, these dependencies need to stick around for the lifetime of the program so they can be imported at runtime. poetry managed those in a separate folder in e. g. the user's cache directory, whereas uv for example stores the virtual environment in the project folder, which I strongly prefer.

cargo will download the matching dependencies (along with doing some caching) and link the correct version to the project, so a conceptual virtual environment doesn't need to exist for Rust. By default, rust links everything apart from the C runtime statically, so the dependencies are no longer neesed after the build - except you probably want to rebuild the project later, so there is some caching.

Finally, I'd also recommend to go and try setting up a project using astral's uv. It handles sane pyproject.toml files, will create/initialize new projects from a template, manages virtual environments and has CLI to build e. g. wheels or source distribution (you will need to specify which build backend to use. I use hatchling), but thats just a decision you make and express as one line in the project file. Note: hatchling is the build backend, hatch is pypa's project management, pretty much an alternative to poetry or uv.

uv will also install complete Python distributions (e. g. Python 3.12) if you need a different interpreter version for compatibility reasons

If you use workspaces in cargo, uv also does those.

uv init, uv add, uv lock --upgrade, uv sync, uv build and how uv handles tools you might want to install and run should really go a long way and probably provide an experience somewhat similar to cargo.

[–] [email protected] 1 points 1 month ago (1 children)

I think you responded to the wrong comment, I didn't question the need for uv or other tools like that

[–] [email protected] 2 points 1 month ago

I did that on purpose, i. e. I wanted to confirm your thoughts about uv, drifted off into a general rant, remembered OP's original question and later realized it would have been better framed as a top level comment. In my defense, I was in an altered state of mind at the time.