[katello-devel] Experience contributing a new feature as a user

[Ivan Nečas]

On Wed 15 Aug 2012 06:06:49 PM CEST, Jason Guiditta wrote:
> On 15/08/12 11:45 -0400, Hugh Brock wrote:
>> On Wed, Aug 15, 2012 at 04:39:03PM +0200, Ivan Nečas wrote:
>>> On 08/15/2012 03:37 PM, Og Maciel wrote:
>>> >Hey Ivan, thanks for the reply. I am actually running Fedora (and
>>> RHEL 6.3) and have tried a mix of yum and gem install commands to
>>> get to a point where I can try to run a simple rspec test... Though
>>> having a script that does what you mentioned, which is, turn a
>>> katello system that was installed and configured into a devel
>>> environment would help me right now, imvho it does not solve what
>>> may be the bigger issue here: why do I need to install the
>>> application in order to run a test? In the rails world all you need
>>> is a test db as you don't actually want to touch the real db.
>>> >
>>> >Also, why can't we just use bundle install like most rails apps?
>>> Sure, you don't have to get all the other moving parts with this
>>> command, such as pulp, candlepin, etc, but at least get enough
>>> dependencies so that one can run tests against it?
>>> >
>>> >As a contributing user I'd like to checkout the source code, run
>>> bundle install, and be able to write and run rpsec tests :)
>>> you would get the same error (with missing ruby-devel) with bundle
>>> install as well. In this case, there is no difference between
>>> `bundle install` and `gem install`. Therefore the RPMs are the
>>> preferred way to do things. And if we had all the devel pacakges in
>>> the "Katello Devel" comps. It would by just as easy as installing
>>> it. It just doesn't help the people without yum.
>>>
>>> pchalupa is working on a better solution for `bundle install` issue
>>> (he has motivation: runs on Mac OS :) The biggest issue right not is
>>> that it's not very clear, how the gem repo is generated (we are
>>> considering to move it go github pages). It also needs a patch in
>>> bundler that will prefer system gems instead of the remote ones. But
>>> we are addressing this.
>>
>> You guys are aware of Jay Guiditta's work on exactly this issue, right?
>> We're currently using a patched Bundler for Aeolus that uses standard
>> gems by default, but will switch to system (rpm-installed) gems if you
>> set the appropriate flag.
>>
>> --H
>>
>
> Just to clarify, it is more of a reuse of the bundle gemfile dsl, the
> library is called bundler_ext, and there is an example usage described
> in the README on github:
> https://github.com/aeolus-incubator/bundler_ext#readme
>
> We currently use an embedded version of this in conductor (exactly the
> same code), and will move to depending on the gem as soon as it gets
> packaged as an rpm (probably post 1.1 for us).
>
>
> Feel free to ping me with questions or issues.
>
> -j

Interesting. In the meantime, we've found another possible way here 
https://github.com/carlhuda/bundler/issues/1964 (dating the same time 
as yours), with a little bit different approach (and little buit monkey 
patching :(. We haven't though about turning bundler off completely for 
those lucky ones with Fedora/RHEL/CentOS, since not all development 
dependencies were packed as RPMs. But we are heading this, in which 
case this approach is much stable, than monkey patching (although at 
the end it seems like just one method alias).

One another concern we have is to provide the same code for developers, 
that is running in production: a gem repo with gems repacked from RPMs 
with the patches applied. Seems funny to see the Gem -> RPM -> Gem 
process, but less funny is to see some random error only on a 
production machine, and we've already hit that. Therefore I'm still 
more fan of having custom gem repos. I have a student working on a RPM 
-> Gem conversion. I will check the progress.

-- Ivan