91–100 of 401 posts
Honest question: is uv more reproducible/portable than cramming your Python project into a Docker container? I've used pyenv, pip, venv, and a couple of other things, and they all work fine, at first, in simple scenarios.
For running containers, pip is best way to go just to keep dependency requirements to minimum.
I'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.
you can solve this with constraints, pip-tools etc., but the argument is uv does this better
Earlier quoted context omitted.
or, you know.. symlinks
Main issue with symlink is needing to choose the source of truth— one needs to be the real file, and the other point to it. You also need to make sure they have the same lifetimes to prevent dangling links. Hardlink is somewhat better because both point to the same inode, but will also not work if the file needs different permissions or needs to be independently mutable from different locations. Reflink hits the swee…
/blobs//filename.zip
and then symlinking/reflinking filename.zip to wherever it needs to be in the source tree...
It's more portable than hardlinks, solves your "source of truth" problem and has pretty wide platform support.
Platforms that don't support symlinks/reflinks could copy the files to where they need to be then delete the blob store at the end and be no worse off than they are now.
Anyway, I'm just a netizen making a drive-by comment.
Honest question: is uv more reproducible/portable than cramming your Python project into a Docker container? I've used pyenv, pip, venv, and a couple of other things, and they all work fine, at first, in simple scenarios.
Can someone explain a non-project based workflow/configuration for uv? I get creating a bespoke folder, repo, and uv venv for certain long-lived projects (like creating different apps?). But most of my work, since I adopted conda 7ish years ago, involves using the same ML environment across any number of folders or even throw-away notebooks on the desktop, for instance. I’ll create the environment and sometimes add n…
In your case, I guess one thing you could do is have one git repo containing you most commonly-used dependencies and put your sub-projects as directories beneath that? Or even keep a branch for each sub-project?
One thing about `uv` is that dependency resolution is very fast, so updating your venv to switch between "projects" is probably no big deal.
Earlier 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.…
Gosh, thanks for sharing! This is the remaining piece I felt I was missing.
I didn't find any mention comparing it to rye. Anyone have any insight? I am pretty distant from the day to day Python ecosystem lately
So it’ll get rolled into UV
Since this seems to be a love fest let me offer a contrarian view. I use conda for environment management and pip for package management. This neatly separates the concerns into two tools that are good at what they do. I'm afraid that uv is another round of "Let's fix everything" just to create another soon to be dead set of patterns. I find nothing innovative or pleasing in its design, nor do I feel that it is parti…
conda user for 10 years and uv skeptic for 18 months. I get it! I loved my long-lived curated conda envs. I finally tried uv to manage an environment and it’s got me hooked. That a projects dependencies can be so declarative and separated from the venv really sings for me! No more meticulous tracking of a env.yml or requirements.txt just ‘uv add` and `uv sync` and that’s it! I just don’t think about it anymore
A very well written article! I admire the analysis done by the author regarding the difficulties of Python packaging. With the advent of uv, I'm finally feeling like Python packaging is solved. As mentioned in the article, being able to have inline dependencies in a single-file Python script and running it naturally is just beautiful. #!/usr/bin/env -S uv run # /// script # dependencies = ['requests', 'beautifulsoup4…
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.…
Adding to the article (which I agree with): Lack of `uv pip install --user` has made transitioning our existing python environment a bit more challenging than I'd like, but not a deal breaker.