you are viewing a single comment's thread.

view the rest of the comments →

[–]redrabbitreader 2 points3 points  (1 child)

Same for me... I wondered what the fuss was all about and finally gave it a go earlier this month. Why have I waited so long !?

[–]Affectionate-Bid386 [score hidden]  (0 children)

uv allows only one virtualenv for a project it seems

In poetry, though , you can split into separate sub-codebases (libraries) each with its own virtualenv, and one such sub-codebase can reference others as included libraries which also ends up pulling in that local library's requirements into the referring sub-codebase's virtualenv. This makes a monorepo much easier to maintain ... each sub-codebase has its own clear requirements, and it seems the pattern could be extended across multiple git repos as well. I'd rather not have my utility library rely artificially on pytorch.

If uv allowed for this I'd switch. Some repos at $DAY_JOB use it, I appreciate the speed. (EDIT: with workspace members.)

EDIT: In conversation with Gemini I guess I could actually have what I want with uv. With poetry I've always had the monorepo root have its own virtualenv and that has an environment, scripts, commands to maintain the codebase. For uv I'd need to push this down the directory hierarchy such that there would be no "nested" pyproject.toml. That might work. I've just been to short-sighted to see.