David Chelimsky on rake 0.9 and gem version constraints(blog.davidchelimsky.net)
blog.davidchelimsky.net
David Chelimsky on rake 0.9 and gem version constraints
http://blog.davidchelimsky.net/2011/05/28/rake-09-and-gem-version-constraints/
7 comments
You can already say "foo _1.2.3_ bar".
That said, I see little benefit in making rubygems bundler-aware, and I think it would constrain both projects in undesirable ways. For example, you propose rubygems checking for a Gemfile, but that is only a convention. Bundler supports an env var to identify the location of a gemfile. So right away, rubygems would need to support both of these techniques. When bundler adds new and better ways to do this, rubygems would have to be updated to keep up. Or, perhaps, it wouldn't, in which case the projects would fall out of sync.
Bundler already offers us simple ways to do this. See http://yehudakatz.com/2011/05/30/gem-versioning-and-bundler-... (including the comments) for more information.
That said, I see little benefit in making rubygems bundler-aware, and I think it would constrain both projects in undesirable ways. For example, you propose rubygems checking for a Gemfile, but that is only a convention. Bundler supports an env var to identify the location of a gemfile. So right away, rubygems would need to support both of these techniques. When bundler adds new and better ways to do this, rubygems would have to be updated to keep up. Or, perhaps, it wouldn't, in which case the projects would fall out of sync.
Bundler already offers us simple ways to do this. See http://yehudakatz.com/2011/05/30/gem-versioning-and-bundler-... (including the comments) for more information.
> You can already say "foo _1.2.3_ bar".
I know. just as I wrote. What I'm saying is that absent this specific version gem executable should check for bundler before blindly choosing the latest.
the check for bundler presence can be easily "outsourced" to bundler. for example "bundle check" will only succeed if it finds bundle installation.
actually, bundler and rubygems should probably just merge.
the check for bundler presence can be easily "outsourced" to bundler. for example "bundle check" will only succeed if it finds bundle installation.
actually, bundler and rubygems should probably just merge.
Great article.. really helps you understand the magic that happens when you type 'bundle install'
I liked Rails better before the Rake 0.9 hiccups exposed the magic.
Now everyone is writing articles to explain the mess. Here's one from Wyatt Greene:
http://techiferous.com/2011/05/the-no-nonsense-guide-to-mana...
Now everyone is writing articles to explain the mess. Here's one from Wyatt Greene:
http://techiferous.com/2011/05/the-no-nonsense-guide-to-mana...
Managing dependencies is a hard problem, and I admire the Ruby community for taking it on, and the big projects (Rails, Rspec) for having the guts to move forward with early implementations.
The payoff will be that setting up Rails apps, installing libraries that are both compatible AND up-to-date, will be fundamentally easier. It will be a competitive advantage for Rails.
No pain, no gain.
The payoff will be that setting up Rails apps, installing libraries that are both compatible AND up-to-date, will be fundamentally easier. It will be a competitive advantage for Rails.
No pain, no gain.
I don't think I would consider package dependencies to be magic. Also, the solution to this whole problem is simply `bundle install --binstubs && bin/rake test`. I don't really think there is much to freak out about.
When a gem has an executable in it rubygems creates a stub capable of running actual code from any gem version by using magic parameter:
foo 1.2.3 bar baz
will run foo from gem version 1.2.3
just 'foo' will run the latest version.
now….
this stub should check for Gemfile presence and initialize bundler.
thats it. it all should work now. 'foo' will run the version specified in the Gemfile.