Re: Proposal for how to handle bundler usage

In doing some thinking about bundler and rpm with regard to our project, there seems to be a couple remaining issues to address. Firstly, how do developers working on a package-system based platform get the correct dependencies if the Gemfile.lock version do not match the latest available on their chosen platform (currently our most common cases are fedora and rhel, which are enough of a problem, this will get even worse once people are also developing on various debian-based setups). On the other hand, what about people developing, on a non package-based system (OSX, windows, even freeform on any linux distro, IOW using gem install or rvm vs rpm/deb)? The Gemfile.lock is a great answer for the second group, but is suboptimal at best for the first group. To this point, we have had a Gemfile and .lock in source control to keep close to in line with what the rails community does, but it has been a somewhat hybrid approach in that we don't allow bundler to look to rubygems.org to resolve dependencies, we expect the developer has done an rpm install of aeolus to make sure the dependencies are satisfied. Obviously, this is because the majority of our team is running on RPM-based systems, and we have been working for the most part on Fedora <insert-latest-version-here>. Assuming we have kept the lock file updated (which has not always been the case), you can run conductor with or without the file present, both for the app and for tests. The problem that starts to crop up is when you have multiple versions of rpm-based distros and people wanting/needing to develop on each. As an example, lets say we have some people working on fedora 15, 16, rhel 6.1, and rhel 6.2 - each with different 'latest' versions of various and sundry gems that conductor depends on. This is not a problem for those on, say, OSX (assuming they have edited our Gemfile and put the rubygems.org link back in), but it is a problem for one of our main use cases of developing on an rpm-based system. A little background on the last time I looked into this. For Rails, rspec, and cucumber, if they do not see a Gemfile or Gemfile.lock in the project directory, they will not attempt to use bundler (I know, hard to believe it is that simple, but it is). This is why running both conductor and tests from an rpm install works as expected (assuming you havent polluted your setup with some combination of rpm _and_ gem installed gems. This made me think, 'why not use this simple fact to make our dev setup work for both kinds of developers?'. There may be other or better ways to make that happen, but here is my proposal (finally): 1. Uncomment the source line in Gemfile so it points to rubygems.org again, as is going to be expected by most ruby developers. 2. Update the lock file on a setup that has the _oldest supported versions of all dependencies_. This is a key point, as it will ensure a minimal baseline without forcing newer distros to hold back updating their packages. 3. Add a rake task, for now I'll call it 'dev:rpm-only', hopefully the name makes it clear why. This task moves off Gemfile and Gemfile.lock to be something else, so they are not picked up for bundler use if you prefer to use rpm. If you are not using and rpm-only setup, and do not mind grabbing the specified versions from the lock file when running 'bundle install', then you can skip this step. Alternativwely we could go in the opposite direction, but as that would be less in keeping with the ruby standard practices, I would prefer not to do that (though I could certainly be conviced). The obvious downfall of this is: * If you are a developer working in rpm-only mode, it will be easy to add a new dependency and forget to add it to gemfile/lock. I think this will not be a large issue if we have a mix of development styles, as someone using the bundler style will notice pretty quickly in most cases that things dont seem to be working as expected. That said, a first step would to be to make it an expectation that any patch with a dependency change should also update the gemfiles (and vice versa if the patch comes from a bundler developer setup). The next step could be another rake task you run whenever you change a dep, soemthing like 'rake dev:update-deps', which could write the changes to the given files for you. Thoughts? If we get general agreement, I'll put this on the backlog so we can get started implementing it. -j