Rails.application.assets.find_asset(‘api.css.scss’)

group :sqlite,  ptional => true do
  gem "sqlite3"
end

You would then do: `bundle install –with sqlite`. However, this didn’t feel entirely satisfying, because it didn’t really hit the nail on the head for the use-cases in question. Your proposal does. I’d want to talk with other Bundler folks before committing to anything, but I think that this actually satisfies an important use-case in an elegant way.

It’s worth noting that bundler would still need to include all of the conditionals in the Gemfile.lock, and they would not be able to have conflicts. You can find more information about the rationale for that at http://gembundler.com/rationale.html#faq-3. However, in most cases where conditionals exist, like database drivers, the drivers don’t conflict with each other, but you only want one, so it would work fine.

This can not be the desired pattern.

I wonder WWYD (What Would Yehuda Do)?

Just look at WordPress and others. It’s ridiculously easy these days to install them and upgrade to a new major version, including migrations being executed for you. Would be nice if there was a default way to add this to a public Rails app.

In Rails 3.x, I think there should no longer BE “shared”/”public” rails apps — all such apps should instead be delivered as engine gems.

This keeps strictly seperate the ‘shared codebase’ part (in the gem, which can specify dependencies in the usual way through it’s gemspec), and the ‘local app’ part, which includes any configuration (such as database.yml), as well as the Gemfile and Gemfile.lock.

The ‘local app’ might have nothing _but_ a database.yml, a Gemfile.lock and a skeleton rails app including the ‘shared’ gem. Or it could have some configuration too. Or it could have some over-rides and local functionality too.

But anything that can be done in an app, in rails 3.x, can be done instead as a skeleton app + engine gem. I think that’s clearly the right way to distribute shared rails apps in 3.x, you should never actually distribute a shared app itself, it should be an engine gem. That eliminates the sort of problems talked about here, has other ancillary benefits, and is what I’ve done with all such things I develop.

There’s no reason you should ever be shipping a Gemfile.lock at all, in theory. You should be shipping a gem with dependencies, the Gemfile.lock should be the LOCAL record of _exactly_ which gems were used in last invocation, as opposed to your gem’s gemspec, which is a listing of ranges of versions acceptable to it. You certainly could lock down to very specific gem versions in the gemspec if you wanted to, though, to get the same effect.

Regarding shipping database drivers in Gemfile.lock: that may be the case, but Bundler is built around the notion that it knows your *entire* dependency graph, including the exact versions that you were using in development, and locks down your gem environment to exactly that. If you don’t include your database drivers in your Gemfile.lock then you won’t have any version guarantees anymore. The alternative is to specify exact versions directly in Gemfile (not Gemfile.lock) and allow the user to regenerate Gemfile.lock, but this makes life extremely hard for the developer. I’ve been down this path and it ain’t pretty.

I’m not sure what you’re getting at with your other statement. Of course the person is lost if something goes wrong, that’s why I’m suggesting a change that makes less things go wrong and less things confusing.