Has someone migrated from poetry to uv? Any benefits?
Mostly less modes of failures, particularly at bootstrapping.
A year of uv: pros, cons, and should you migrate
151–160 of 401 posts
Re: A year of uv: pros, cons, and should you migrate
#152Earlier quoted context omitted.
Maybe I'm missing something, but why wouldn't you just pin to an exact version of `requests` (or whatever) instead? I think that would be equivalent in practice to limiting resolutions by release date, except that it would express your intent directly ("resolve these known working things") rather than indirectly ("resolve things from when I know they worked").
Pinning deps is a good thing, but it won't necessarily solve the issue of transitive dependencies (ie: the dependencies of requests itself for example), which will not be pinned themselves, given you don't have a lock file. To be clear, a lock file is strictly the better option—but for single file scripts it's a bit overkill.
One could indicate implicit time-based pinning of transitive dependencies, using the time point at which the dependended-on versions were released. Not a perfect solution, but it's a possible approach.
Re: A year of uv: pros, cons, and should you migrate
#153I've been mostly out of the python game for quite a while, but I never had that much issue with: pip install -r requirements.txt . Seems like a lot of people have tried their hand at various tooling, so there must be more to it than I am aware of.
I write internal tools using Python at work. These tools are often used by non-Python devs. I am so, so tired of adding a blurb on creating a venv.
(Of course, the alternative—"install this software you've never heard of"—isn't fantastic either. But once they do have it, it'd be pretty neat to be able to tell them to just "uvx ".)
Re: A year of uv: pros, cons, and should you migrate
#154The challenge I have with adopting uv is it feels like it doesn't have a great replacement for poetry's `[tool.poetry.scripts]` block.
For instance, from a personal project that uses a src layout, without being a package, I have this in my pyproject.toml:
[tool.poetry] ... packages = [{ include = "*", from = "src", format = "sdist" }] ...
[tool.poetry.scripts] botch = "launcher:run_bot('botch')" beat = "launcher:run_bot('beat')"
I can't find any way to get that working in uv without some pretty major refactoring of my internal structure and import declarations. Maybe I've accidentally cornered myself in a terrible and ill-advised structure?
Re: A year of uv: pros, cons, and should you migrate
#155I thought this was going to be about the UV rays from the sun... But it's another python package manager. We're running out of names.
I think you mean running out of acronyms. What is CS? 1. Computer Science 2. Customer Service 3. Clinical Services 4. Czech 5. Citrate synthase 6. Extension for C# files
It's Counter Strike of course
Re: A year of uv: pros, cons, and should you migrate
#156Earlier quoted context omitted.
One other key part of this is freezing a timestamp with your dependency list, because Python packages are absolutely terrible at maintaining compatibility a year or three or five later as PyPI populates with newer and newer versions. The special toml incantation is [tool.uv] exclude-newer: # /// script # dependencies = [ # "requests", # ] # [tool.uv] # exclude-newer = "2023-10-16T00:00:00Z" # /// https://docs.astral.…
Maybe I'm missing something, but why wouldn't you just pin to an exact version of `requests` (or whatever) instead? I think that would be equivalent in practice to limiting resolutions by release date, except that it would express your intent directly ("resolve these known working things") rather than indirectly ("resolve things from when I know they worked").
Except at least for the initial run, the date-based approach is the one closer to my intent, as I don't know what specific versions I need, just that this script used to work around specific date.
Re: A year of uv: pros, cons, and should you migrate
#157uv has been fantastic for most of my personal projects. It feels so much smoother than any other python tooling combo I tried in past. That said, it just does not work well behind corporate proxies. This is single most annoying thing that has stopped me from recommending it at work.
Re: A year of uv: pros, cons, and should you migrate
#158Has anyone built pipy packages with `uv`? Does doing so affect the end-user at all?
Re: A year of uv: pros, cons, and should you migrate
#159I know good naming is hard, and there are an awful lot of project names that clash, but naming a project uv is unfortunate due to the ubiquitous nature of libuv https://libuv.org/
I don't think it's particularly problematic, uv the concurrency library and uv the Python tool cover such non-overlapping domains that opportunities for confusion are minimal. (The principle is recognized in trademark law -- some may remember Apple the record label and Apple the computer company. They eventually clashed, but I don't see either of the uv's encroaching on the other's territory.)
Sure, there are so few backend Node.js engineers. Let alone game engine developers and Blender users with their UV mapping tools. None of these people will ever encounter Python in their daily lives.
Re: A year of uv: pros, cons, and should you migrate
#160Has anyone built pipy packages with `uv`? Does doing so affect the end-user at all?
What do you mean by building a pipy package?
If you mean creating and publishing packages to PyPI end users can't tell if you used uv or poetry or something else.