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

91–100 of 105 posts

Re: Can Bundler be as fast as uv?

#91

Post by olivierlacan »

franciscop wrote: post #86

> 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 di…

Had the same thought reading this but I suspect what's in the gemspec could accidentally differ from what's in the RubyGems.org metadata, although that should probably not be possible.

From working on RubyGems.org a long time ago I vaguely remember that the metadata extracted from the gemspec is version-specific. So if you add a new native_extension boolean you'd have to artificially reprocess those previously published gemspecs to change the metadata for all past versions.

Being able to mutate metadata for past versions is dangerous enough that I'd be surprised it's allowed or even possible. So that might not even be something Aaron considered here for that reason. That said, it seems reasonable to me to suggest this improvement going forward to make unpacking the gem unnecessary to know whether it'll affect installation order.

Re: Can Bundler be as fast as uv?

#92

Post by charliermarsh »

quotemstr wrote: post #14

Well, now my opinion of uv has been damaged. It... > Ignoring requires-python upper bounds. When a package says it requires python Man, it's easy to be fast when you're wrong. But of course it is fast because Rust not because it just skips the hard parts of dependency constraint solving and hopes people don't notice. > When multiple package indexes are configured, pip checks all of them. uv picks from the first index…

> Man, it's easy to be fast when you're wrong. But of course it is fast because Rust not because it just skips the hard parts of dependency constraint solving and hopes people don't notice.

We ignore upper bounds because it leads to a better solve. You can read my comment here: https://news.ycombinator.com/item?id=46464453. There's significant discussion about this, e.g., here: https://discuss.python.org/t/requires-python-upper-limits/12....

> Ambiguity detection is important.

I think you're misunderstanding why we do this: it's a security feature. pip's design is inherently vulnerable to dependency confusion attacks, since packages of the same name across indexes are considered equally trusted by pip. You can look up the torchtriton attack to learn more.

> Stuff like this sense unlikely to contribute to overall runtime, but it does decrease flexibility.

I think you're misinformed. We support all of these features: system- and per-user configuration files, environment variables, etc. We just don't read _pip's_ configuration file, which is intended for pip, not uv.

Re: Can Bundler be as fast as uv?

#93

Post by raggi »

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…

At runtime rather than install time yes. I did some prototyping on this back in the day, one of the issues is the language lacks an efficient data structure to store that information and you can’t (easily) build one efficiently because instances are too heavy.

Re: Can Bundler be as fast as uv?

#94

Post by ecshafer »

pantulis wrote: post #80
Kwpolska wrote: post #77

Earlier quoted context omitted.

There is no single established framework/language for backend Web development. There are many options, all valid, differing in popularity based on their qualities (or sometimes just hype). Ruby used to be cool around 2010, but it lost to better options. Ruby has strange syntax, and Rails abuses magic, so I guess the viability of TypeScript for development made Ruby less popular.

> Ruby used to be cool around 2010, but it lost to better options. I'd argue that it lost the cool kidz mindshare but not to better options. People jumped to Node.js because of async but in the end the relevant industry change was the switch to SPA based architectures in the web space. Rails never embraced that approach and hence lost the popularity. Jump 15 years ahead, and now the Enterprise world is built with Rea…

IMO I think that the industry will start to move away from React and Angular. These apps take too much developer time for basic functionality, are too slow, and too much of a maintenance burden. The Future^TM is HTMX like functionality, which Rails is very well positioned for with Turbo + Stimulus. I rewrote some pages that had Rails backends with React front ends to Turbo + Stimulus, and the code base size drastically shrank, the performance increased, the maintenance time for features dropped, and it was even more reactive than before.

Re: Can Bundler be as fast as uv?

#95

Post by busterarm »

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.)

That takes me back. I haven't used GoboLinux since maybe 2007ish but I used to maintain several packages for it.

It's not really that easy being really different in the Linux packaging world.

Re: Can Bundler be as fast as uv?

#96

Post by busterarm »

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…

You post about Shopify/DHH/gem.coop constantly, guy. In any thread related to anything Ruby, regardless of how tangential.

Give it a rest.

Re: Can Bundler be as fast as uv?

#97

Post by beanjuiceII »

stouset wrote: post #32
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.

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

to me the languages themselves should handle it

Re: Can Bundler be as fast as uv?

#98

Post by yxhuvud »

byroot wrote: post #83
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.

Perhaps its time to try again - bootsnap is definitely stable enough now, which it really wasn't early on.

Re: Can Bundler be as fast as uv?

#99

Post by derefr »

olivierlacan wrote: post #91
franciscop wrote: post #86

> 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 di…

Had the same thought reading this but I suspect what's in the gemspec could accidentally differ from what's in the RubyGems.org metadata, although that should probably not be possible. From working on RubyGems.org a long time ago I vaguely remember that the metadata extracted from the gemspec is version-specific. So if you add a new native_extension boolean you'd have to artificially reprocess those previously publis…

Just make the rule apply only to packages published after a given date, and then manually backfill that metadata into the service-backend DB with a one-time scrape through all packages from before that date.

Re: Can Bundler be as fast as uv?

#100

Post by stouset »

jacobtomlinson wrote: post #79
dirtbag__dad wrote: post #56

Earlier quoted context omitted.

Can you help me understand what the value or use case of poethepoet is?

It allows you to define common tasks such as linting, running tests, building docs, etc under an alias. So you can run uv run poe docs Instead of uv run sphinx-build -W -b dirhtml docs/source docs/build Many languages have a task runners baked into their package manager, but many others don’t. In Ruby it’s roughly the equivalent of Rake.

I think the question being asked is, if you’re already using mise (which has a built-in task runner) what is the advantage of going with the other one?
Post reply on HN