On Thu, Jan 10, 2013 at 11:52:24AM +0000, Adam Spiers wrote:
Ralf Haferkamp (rhafer@suse.de) wrote:
On Thu, Jan 10, 2013 at 10:34:19AM +0000, Adam Spiers wrote:
Ralf Haferkamp (rhafer@suse.de) wrote:
On Wed, Jan 09, 2013 at 01:37:18PM +0100, Josef Reidinger wrote:
On Wed, 9 Jan 2013 13:25:22 +0100 Ralf Haferkamp <rhafer@suse.de> wrote:
[..]
Yeah, this is the approach (or at least a similar one) I am currently trying as well. I created a small script that parses the Gemfile an filters out unneeded groups and platforms and generates a new Gemfile from that.
I think upstream have a good reason for not doing this. "bundle help install" says:
This is so that installing a different set of groups on another machine (such as a production server) will not change the gems and versions that you have already developed and tested against.
Bundler offers a rock-solid guarantee that the third-party code you are running in development and testing is also the third-party code you are running in production. You can choose to exclude some of that code in different environments, but you will never be caught flat-footed by different versions of third-party code being used in different environ- ments.
Would it be a lot more pain/effort to ensure that there are gem packages for all the environments? Even if they were covered by BuildRequires for crowbar-barclamp-crowbar, they wouldn't have to go in the final ISO.
I stopped adding all the gems to BuildRequires, as they are not needed for building the package. As Josef noted bundle install does not need to be called during the build. (It will be implicitly called, when starting the app for the first time though.)
Yeah, but doesn't that break the guarantee described above? which slightly worries me. Don't we run our tests based on the packages from the ISO (+ probably the update channels). I think that provides a similar guarantee, right?
It should however be possible to create "-devel" and "-test" subpackages that just add the dependencies for the respective Gemfile groups. BTW, I created rpm for most of the devel and test dependencies in home:rhafer:branches:systemsmanagement:crowbar:2.0 while experimenting with the packaging.
Cool, I like that subpackage idea a lot. If it's not a lot of work to finish packaging all the dev/test gems, then Gemfile.lock could be created at build-time and we could preserve the bundler guarantee, which IMHO would be better. That would bring back a pretty long list of BuildRequires, with all it's drawbacks. (much larger buildroot, longer build times, more rebuilts). Addtionally I think we would still need to fiddle around with the Gemfile, because of the ruby18 (rcov) vs. ruby19 (scov) problems I mentioned above.
I'm not sure where the break-even point is on the cost:reward ratio though. Me neither. I would rather not spent much more time on this currently.
-- Ralf -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org