3:03 p.m.
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