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

101–105 of 105 posts

Re: Can Bundler be as fast as uv?

#101

Post by Dylan16807 »

shevy-java wrote: post #70
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".

Hmmm. Aaron is cool, but also works at Shopify. Neither DHH nor Aaron mentioned anyone at the gem.coop project. I can't help but have mixed feelings here. I think the underlying issue is much bigger than merely contained on speed. It also has to do with control - both for developers as well as users. This is also why I think the label "prematurely" is weird, because it attempts to singularize everything down to the s…

Are you just complaining about ruby in general? I don't see how "control" or "purge away old developers" has any connection to bundler.

Re: Can Bundler be as fast as uv?

#102

Post by vinceguidry »

plorkyeran wrote: post #63
chao- wrote: post #58

Earlier quoted context omitted.

I'm always surprised to hear this, and I want to be clear that I'm not trying to be dismissive in my comment. However, I've not encountered issues while juggling dozens of Ruby projects since around 2011, despite seeing many people's complaints over the years. Ten years ago I was using rvm, and I saw people sharing their issues with it, and listing reasons why rbenv and chruby are better. So I tried those, and my res…

My experience with the ruby ecosystem has been that if you get everything set up correctly all of the environment management tools have worked wonderfully. When you don't have everything set up correctly, they break in ways that is hard to understand for someone not intimately familiar with the ecosystem. It's something that's not at all a problem for someone using ruby as their primary language, and a major source o…

For a long time I avoided projects written in Python for this same reason, though they seem to have resolved the issues over time. The only stack these days that gives me pause is nodejs, but for different reasons.

Re: Can Bundler be as fast as uv?

#103

Post by nightpool »

solatic wrote: post #76
nightpool wrote: post #3

Really interesting post, but this part from the beginning stuck out to me: Ruby Gems are tar files, and one of the files in the tar file is a YAML representation of the GemSpec. This YAML file declares all dependencies for the Gem, so RubyGems can know, without evaling anything, what dependencies it needs to install before it can install any particular Gem. Additionally, RubyGems.org provides an API for asking about…

For a "YAML" lockfile, you could probably write a much simpler and much more performant parser that throws out much of what makes YAML complicated, in particular, anchors, data type tags, all the ways of doing multi-line strings, all the weird unexpected type conversions (like yes/no converting to a boolean)... If the lockfile is never meant to be edited by human hands, only reviewed by human eyes, you can build a mu…

This is about the gemspec (e.g. the project or package file, like pyproject.toml or package.json) for each dependency. The lock file is in a custom plain text format to make it easy for both humans and bundler to understand

Re: Can Bundler be as fast as uv?

#104

Post by nightpool »

tedivm wrote: post #57
nightpool wrote: post #3

Really interesting post, but this part from the beginning stuck out to me: Ruby Gems are tar files, and one of the files in the tar file is a YAML representation of the GemSpec. This YAML file declares all dependencies for the Gem, so RubyGems can know, without evaling anything, what dependencies it needs to install before it can install any particular Gem. Additionally, RubyGems.org provides an API for asking about…

It mostly doesn't matter, because these metadata files are pulled into their respective package managers. When you publish to RubyGems the file is read into their database and made available to their API, just like when you publish a Python file the pyproject.toml is parse into the PyPI database and made available. This is a major reason why UV is faster than older python package managers, as they were able to take a…

Ah, I had misremembered the article as saying that the API was sufficient for "most" tasks, all it actually says is that it's the "normal" way of getting the dependency info. I was wondering if there was some less common operations (e.g. upgrading?) that needed more info beyond what was in the API.

Re: Can Bundler be as fast as uv?

#105

Post by lamontcg »

vidarh wrote: post #81
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…

Yeah, chef-client got a lot faster, particularly on Windows, just by liberally using `require_relative` whenever possible and sprinkling `require "Foo" unless defined?(FOO)` all over the codebase.
Post reply on HN