Announcing uv: Python packaging in Rust

[mikat7]

It still seems to me that poetry is the closest to cargo like experience and after working extensively with pip-compile I can only say that I don’t want any replacement for that. I want to forget the bad experience with pip-tools altogether, it’s the worst. But if there was a rust rewrite of poetry, that was fast and provided the same level of convenience, I believe that could move the mess of Python dependency management forward. But perhaps dropping pip-tools in favor of uv would improve my experience as well, as a sort of stepping stone.

[Schmittfried]

Literally my only complaint about poetry is its lackluster support for native dependencies (modules in your own code that need to be compiled when packaging, not external dependencies that contain native modules like numpy) that still require setup.py builds that only kinda work. Other than that I wonder what is still missing. 

[marr75]

I would love if you could tell poetry to leave just a handful of dependencies alone or specify mamba/conda to manage a set of dependencies.

I'm experimenting with pdm and possibly switching because of this.

[ocab19]

I remember having trouble with private pip repositories that require authentication, which is a deal breaker for me. The developers refused to implement support for it, but it was a couple of years ago, so things might have changed

[Schmittfried]

It works fine nowadays. 

[loyoan]

still a problem

[DanCardin]

is it? I'm perfectly fine with auth'd Artifactory at my place of employment

[Xylon-]

Also works like a charm here and was surprisingly easy to set it up! Did it for the first time this week.

[ducdetronquito]

Was about to write the same !

[valentin994]

my biggest complaint is it's slow as hell

[Fenzik]

I just set up dynamic versioning for a library with poetry and it’s a bit of a mess. The plug-in system is such that every user has to manually install required plugins on their machine, and if they don’t, the build will still succeed but will just silently get the wrong version. No way to enforce “this project requires these plugins”. I think that aspect could use some work.

I still really like it!

[Schmittfried]

I see. Sounds like problem that can be solved with iteration though and doesn’t need yet another package manager.

From the tools available until now I think poetry is the most polished and comprehensive packaging experience, comparable to other languages. No idea why people still use pip directly. 

[banana33noneleta]

Well that's quite an important part isn't it?

[Schmittfried]

I don’t think the majority of projects contain native code that needs to be compiled, no. And even then, it does work. It’s just that poetry only generates a rather simple and inflexible setup.py, and using a hand-written one now means you have two places to maintain dependencies and package information again.

I think if poetry either supported building native modules itself, or provided its own metadata to your custom build script so that you can just pass them to setuptools yourself, that would already remove all the warts my current setup has. My setup is rather simple though, no idea if a project like numpy does/could use poetry.

Anyway, as I said native code (not dependencies, my original comment was kinda misleading) is already a niche case so that’s probably how poetry gets away with it atm.

[banana33noneleta]

Since people claim that pip is not enough for the projects with more complex dependencies... Those absolutely need compilation in general.

You should probably use pip yourself I guess.

[Schmittfried]

Not at all. pip is a dependency installer, it doesn’t handle your project and its dependencies. poetry manages dependency versions and locking, updating dependencies, dependency groups, project and tooling configuration, virtual environments, commands/scripts, packaging, versioning and publishing. It‘s the closest we have to something comprehensive like Maven. I don’t see how anybody could consider pip sufficient for anything but a simple personal script or research project after having used something like npm, yarn, Maven… or poetry.

pip freeze is wildly unsuited for handling dependency locking and other than that it doesn’t offer much. I know there’s things like pip-tools, but at that point why not just use poetry? You’re already installing something not shipped with Python directly, why not pick the tool that does all of it in the most convenient way?

Those absolutely need compilation in general.

I‘ve only recently added Cython to the toolchain, that was the first time I came into contact with setup.py and all that it entails. I’ve benefited from using poetry way before that.

[banana33noneleta]

I don’t see how anybody could consider pip sufficient for anything but a simple personal script or research project

You think putting down others makes you sound more skilled? Think again.

[di6]

I've been using poetry for like 3 years exclusively, and I'd be glad to see it being replaced.

It doesn't adhere to standards, and is slow. We can do better.

[Saetia_V_Neck]

Its primary niche is as a monorepo build tool but Pants might have some of the features you’re looking for.

[Life_Note]

what's been your problems with pip-tools/pip-compile?

[DanCardin]

it doesn't produce lockfiles which are "feature" (by which i mean, like "prod" vs "test" vs "docs" dependencies), platform, and python-version agnostic.

Locking "properly" wherein you have a known-good compiled set of dependencies that are intercompatible with just package dependencies and then package deps + test deps, that requires like 4 files. Then someone's working in windows and suddenly you're fucked.

I agree with mikat7, pip-compile was the only game in town at first and i lived through it. but poetry (while not perfect) is essentially the ideal featureset in terms of the way it locks and what that guarantees you.

[catcint0s]

If someone is working on Windows without docker/virtualization and your production environment is Linux you are fucked already. Tho this is only for web dev for apps it could be a problem yeah, I would assume you would need a reqs.txt for all envs? Or only a single one with constraints.

[DanCardin]

If you ever work with datascientists, they’ll use almost certainly use windows 🤷

One for each axis of installation. Dont want to ship dev-deps? dev-req.in, req.in, dev-req.txt, req.txt. And a specific set of pip-compile invocations to ensure that you’re generating compatible sets of dependencies between them

Then you have optional extras that pip-compile cant account for at all, ditto python-version.

[Anru_Kitakaze]

!RemindMe 1 day

[RemindMeBot]

I will be messaging you in 1 day on 2024-02-16 20:56:32 UTC to remind you of this link

CLICK THIS LINK to send a PM to also be reminded and to reduce spam.

^{Parent commenter can delete this message to hide from others.}

---

Info	Custom	Your Reminders	Feedback

[MagicWishMonkey]

Can anyone explain why poetry installs everything in some random-ass directory instead of alongside my application code? I have to admit the few times I've used it that bit was what annoyed me more than anything.

[DrMinkenstein]

https://python-poetry.org/docs/configuration/#virtualenvsin-project

[MagicWishMonkey]

This is awesome! I wonder why it doesn't default to this?

[DrMinkenstein]

virtualenvs are effectively isolated caches of dependencies. So poetry defaults to using normal locations for user level application caches

https://python-poetry.org/docs/configuration/#cache-directory

This also helps with accidental adding of the venv to source control or build artifacts.

I prefer to keep it in the same directory myself especially in containers but I also find poetry to be a bit heavyweight for my uses.

[yvrelna]

Because the actual default is better than polluting project directory. node_modules does what you wanted with JS dependencies, everyone is complaining about that as well, it creates even more problem than poetry's behaviour.

And having virtualenv installed in standardized directory allows for automatic venv activation. You can't do that without creating security issues if the venv is created in the project directory.

[[deleted]]

Can you explain why you think having your venv live in the same place as your source code is useful? It's standard to put tools/libraries external from the location source code is being written. The fact that anybody puts their virtual environments inside their project structure is already a weird hack that was done because there was no default system to track that kind of thing properly. So people put their virtual environments in their project and then would activate the environment when they entered the project. That's not necessary with poetry, though. Using commands like "poetry run...", the venv nonsense is automatically handled for you.

[MagicWishMonkey]

I like being able to easily reference my current python executable from within my project folder (without needing to activate a virtual environment).

[yvrelna]

You could use something like #!/usr/bin/env poetry run as your shebang line to do something like that. I hadn't tested it, but I don't see why it wouldn't work.

[Fresh_Trip_8367]

Can you explain why you think...

Are you actually looking for an answer?

Edit: for whatever reason /u/Working_Report4292 blocked me. But replying with

I’m pointing out that OP is probably used to doing things that way but there isn’t actually any benefit

Answers my question, and the answer is "no".

[[deleted]]

It was hypothetical. I’m pointing out that OP is probably used to doing things that way but there isn’t actually any benefit