Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Can Bundler be as fast as uv?

tenderlovemaking.com

Post reply on HN
Print view View original

81–90 of 105 posts

Re: Can Bundler be as fast as uv?

#81

Post by vidarh »

lamontcg wrote: post #50

The biggest thing that gems could do to make rubygems faster is to have a registry/database of files for each gem, so that rubygems didn't have to scan the filesystem on every `require` looking for which gem had which file in it. That would mean that if you edited your gems directly, things would break. Add a file, and it wouldn't get found until the metadata got rehashed. The gem install, uninstall, etc commands wou…

100%. Optimising "bundle install" etc. is optimizing the wrong thing. You don't even need this to work from gems in general. It'd have solved a lot of problems just to have it work for "bundle install" in standalone mode, where all the files are installed to a directory anyway.

But in general, one of the biggest problems with Ruby for me is how $LOAD_PATH causes combinatoric explosion when you add gems because every gem is added, due to the lack of any scoping of require's to packages.

The existence of multiple projects to cache this is an illustration that this is a real issue. I've had project in the past where starting the app took minutes purely due to require's, and where we shaved minutes off by crude manipulation of the load path, as most of that time was pointless stat calls.

Re: Can Bundler be as fast as uv?

#82

Post by byroot »

maccard wrote: post #48
byroot wrote: post #41

Earlier quoted context omitted.

> My experience with GHA default caches is that it’s absolutely dog slow. GHA is definitely far from the best, but it works:, e.g 1.4 seconds to restore 27 dependencies https://github.com/redis-rb/redis-client/actions/runs/205191... > The only way docker caching works is if you have a persistent host. You can pull the cache when the build host spawns, but yes, if you want to build efficiently, you can't use ephemeral…

> So I'll just reiterate my main point: a CI system must provide a workable caching mechanism if it want to be both snappy and reliable. The problem is that none of the providers really do this out of the box. GHA kind of does it, but unless you run the runners yourself you’re still pulling it from somewhere remotely. > I've worked for over a decade on one of the biggest Rails application in existence, and restoring…

> none of the providers really do this out of the box

CircleCI does. And I'm sure many others.

Re: Can Bundler be as fast as uv?

#83

Post by byroot »

lamontcg wrote: post #50

The biggest thing that gems could do to make rubygems faster is to have a registry/database of files for each gem, so that rubygems didn't have to scan the filesystem on every `require` looking for which gem had which file in it. That would mean that if you edited your gems directly, things would break. Add a file, and it wouldn't get found until the metadata got rehashed. The gem install, uninstall, etc commands wou…

You are describing bootsnap.

And yes I proposed to integrate bootsnap into bundler ages ago, but got told to go away.

Re: Can Bundler be as fast as uv?

#84

Post by merelysounds »

shevy-java wrote: post #72
stouset wrote: post #32

Earlier quoted context omitted.

Mise is the answer to this. I no longer use chruby/rbenv/rvm. And it manages multiple languages, project-local environment, etc.

Well. GoboLinux solved that already. Back in 2005. I never understood the real need for chruby rvm etc... - I manage everything, all programs, in a versioned AppDir manner. (Note: I am not using GoboLinux; I use a modified variant. GoboLinux gave the correct idea though.)

Context for anyone unfamiliar with GoboLinux:

> each program in a GoboLinux system has its own subdirectory tree, where all of its files (including settings specific for that program) may be found. Thus, a program "Foo" has all of its specific files and libraries in /Programs/Foo, under the corresponding version of this program at hand. For example, the commonly known GCC compiler suite version 8.1.0, would reside under the directory /Programs/GCC/8.1.0

https://en.wikipedia.org/wiki/GoboLinux

Re: Can Bundler be as fast as uv?

#85

Post by black3r »

riffraff wrote: post #36
AlphaSite wrote: post #23

Earlier quoted context omitted.

Speed would be nice, but more than that I want it to also manage Ruby installs. I’m infuriated at the mess of Rubys and version managers.

what exactly is your issue? I've been using rvm for a decade(?) without any major pain. Cross-language tools such as mise or asdf also seem to work ok. I can relate to the "I wish we didn't need a second tool", but it doesn't seem like much of a mess.

I've been using pyenv for a decade before uv and it wasn't a "major pain" either. But compared to uv it was infinitely more complex, because uv manages python versions seamlessly.

If python version changes in an uv-managed project, you don't have to do any extra step, just run "uv sync" as you normally do when you want to install updated dependencies. uv automatically detects it needs a new python, downloads it, re-creates the virtual environment with it and installs the deps all in one command.

And since it's the command which everyone does anytime a dependency update is required, no dev is gonna panic why the app is not working after we merge in some new code which requires newer python cause he missed the python update memo.

Re: Can Bundler be as fast as uv?

#86

Post by franciscop »

> PEP 658 (2022) put package metadata directly in the Simple Repository API, so resolvers could fetch dependency information without downloading wheels at all.

> Fortunately RubyGems.org already provides the same information about gems.

> [...]

> After we unpack the gem, we can discover whether the gem is a native extension or not.

Why not adding the meta information of whether the gem is a native extension or not directly to rubygems.org? You could fully parallelize whole installation trees of dependencies then.

Re: Can Bundler be as fast as uv?

#87

Post by pasc1878 »

shevy-java wrote: post #72
stouset wrote: post #32

Earlier quoted context omitted.

Mise is the answer to this. I no longer use chruby/rbenv/rvm. And it manages multiple languages, project-local environment, etc.

Well. GoboLinux solved that already. Back in 2005. I never understood the real need for chruby rvm etc... - I manage everything, all programs, in a versioned AppDir manner. (Note: I am not using GoboLinux; I use a modified variant. GoboLinux gave the correct idea though.)

And the bank where I worked in mid 1990s had the same each program in its own versioned directory.

Re: Can Bundler be as fast as uv?

#88

Post by angristan »

AlphaSite wrote: post #23
dbalatero wrote: post #8

I appreciate that Aaron is focusing on the practical algorithm/design improvements that could be made to Bundler, vs. prematurely going all in on "rewrite in Rust".

Speed would be nice, but more than that I want it to also manage Ruby installs. I’m infuriated at the mess of Rubys and version managers.

Maybe https://github.com/spinel-coop/rv will be the answer when it's ready

Re: Can Bundler be as fast as uv?

#89

Post by 0x696C6961 »

NSPG911 wrote: post #53
stouset wrote: post #32

Earlier quoted context omitted.

Mise is the answer to this. I no longer use chruby/rbenv/rvm. And it manages multiple languages, project-local environment, etc.

mise is pretty nice, though I don't use it for python, Python is handled by uv with poethepoet as the task runner.

FWIW mise has a task runner built-in too.

Re: Can Bundler be as fast as uv?

#90

Post by charliermarsh »

I'm not super familiar with Bundler's architecture but I think the most impactful thing would be adopting uv's cache design, which is a big part of what makes uv so fast and should be replicable in other languages and ecosystems.

> Ignoring requires-python upper bounds. When a package says it requires pythonI don't think that ignoring upper bounds has a significant impact on uv's performance. We do this for a totally different reason, which is that it leads to better solves. For example, if you say your project requires Python 3.8 or later, but some dependency said it works for ">=3.8,(See, e.g. https://discuss.python.org/t/requires-python-upper-limits/12....)

Post reply on HN