Rv, a new kind of Ruby management tool

As a long-time Rubyist and recent Python dabbler (due to pytorch) this is exciting! Uv and uvx certainly are great improvements in the Python ecosystem, but still have some quirks that I wonder how they will handle with rv:

- By default uv is creating isolated environments in the project directory and will download all dependencies over the network. For small stuff this isn't too bad, but re-downloading 700mb pytorch each time you clone a repo gets annoying very fast. Of course there are trade-offs with running updates less frequently (and uv has flags such as --offline and --refresh to avoid or force online access) but more sensible default behavior would be nice so that uv (and rv) keep you on the happy path during developing. Maybe updates could be run in the background by default.

- Also because the environments aren't shared in any way, each project directory consume a lot of disk space (10x checkouts = 10x pytorch on disk). More sensible caching across environments would be nice (links?).

- Using uv to turn Python files into standalone/self-contained scripts is really great (https://peps.python.org/pep-0723/) and I hope rv can mirror this capability well. Because the lock file isn't included in the script header it requires some configuration options to make runs repeatable (e.g. https://docs.astral.sh/uv/guides/scripts/#improving-reproduc...).

- I am wondering if rv will support version operators such as rv install "~> 3.4.4" to get ruby ">= 3.4.4, < 3.5.0", which I think would help ensure everyone is running Ruby versions with security patches applied.

- uv includes the pip sub-command (similar to using gem install rather than bundle add) but because the environments are isolated this feels rather weird and I haven't really understood in which cases you should not just use "uv add" to update your project dependencies.

- Uv tries hard to support migration from legacy Python projects which don't have a pyproject.toml, but the Python eco-system is too fragmented for this to always work. I hope rv can avoid adding new config files, but really stick to the existing Gemfile approach.

- If a Python package includes a script with a different name than the package then the syntax is a bit annoying ('uvx --from package script' but not 'uvx script --from package' because this would get passed to the script). Uv already uses square brackets for optional project dependencies (e.g. 'uvx --from huggingface_hub[cli] hf') but since Ruby doesn't have these, maybe this would be an option for rv.

uv doesn't redownload every dep every time. If the dep is the same, it uses a hardlink: no additional download, no additional space taken.

Pip subcommands are here to ease the transition from the old ecosystem to the new.

Edit: maybe I need to investigate this again because it isn't working for me. In a usual month I downloaded pytorch through UV maybe 100 times.

Not true, each virtual environment has its own physical copy on disk.

Since creating venvs is usually per project you have many downloads / copies.

See: https://github.com/astral-sh/uv/issues/1495

Hard links are already used, when available. Are you on windows?

On WSL indeed, I must mis-interpreting my issues with re-downloading to indicate that the files wouldn't be shared. I guess I must investigate that more, why I am seeing so many redownloads.

uv uses very agressive caching (https://docs.astral.sh/uv/concepts/cache/) but pytorch has many, many different combinations of packages for the same release.

It's not uncommon to have to download pytorch many times, because some lib may specify one slightly different version than another: https://docs.astral.sh/uv/guides/integration/pytorch/#config...

pytorch causes many headaches in the ecosystem, and a better handling of it is one thing their commercial offering, pyx, wants to fix: https://astral.sh/blog/introducing-pyx