Need to add minitest to Gemfile

Vít Ondruch vondruch at redhat.com
Thu Aug 16 10:06:58 UTC 2012


Dne 14.8.2012 16:29, Jason Guiditta napsal(a):
> On 14/08/12 09:38 +0200, Vít Ondruch wrote:
>> Dne 13.8.2012 20:25, Jason Guiditta napsal(a):
>>> On 13/08/12 14:11 -0400, Jason Guiditta wrote:
>>>> On 11/08/12 09:14 -0400, Hugh Brock wrote:
>>>>> On Fri, Aug 10, 2012 at 04:44:34PM +0200, Vít Ondruch wrote:
>>>>>> Dne 9.8.2012 19:36, Jason Guiditta napsal(a):
>>>>>>> On 09/08/12 09:18 -0700, Crag Wolfe wrote:
>>>>>>>> On 08/09/2012 06:46 AM, Jason Guiditta wrote:
>>>>>>>>> On 08/08/12 17:22 -0700, Crag Wolfe wrote:
>>>>>>>>>> conductor/src/Gemfile currently does not have a dependency for
>>>>>>>>>> minitest, but it should. I ran into this while trying to run 
>>>>>>>>>> "bundle
>>>>>>>>>> exec rake spec" and "bundle exec rake cucumber" in a
>>>>>>>>>> bundler-development environment (thanks Richard for helping 
>>>>>>>>>> me debug
>>>>>>>>>> this).
>>>>>>>>>>
>>>>>>>>>> I'm not certain whether this dependency belongs in the top 
>>>>>>>>>> section as
>>>>>>>>>> "gem 'minitest' (which works fine for me) or just under "group
>>>>>>>>>> :development, :test do"
>>>>>>>>>>
>>>>>>>>>> --Crag
>>>>>>>>>>
>>>>>>>>>> P.S. Is there a reason we don't have the lists of gems in 
>>>>>>>>>> Gemfile
>>>>>>>>>> alphabetized? :-)
>>>>>>>>>
>>>>>>>>> Where do you see a dep needed on minitest? I have an rvm 
>>>>>>>>> gemset with
>>>>>>>>> only gems install by bundler (which does not include 
>>>>>>>>> minitest), and it
>>>>>>>>> seems fine. If we really did need it for some reason, where it
>>>>>>>>> goes should be the dev/test block - requiring a test library 
>>>>>>>>> to run
>>>>>>>>> the main app would be madness and a bug to be fixed, imo.
>>>>>>>>>
>>>>>>>>> -j
>>>>>>>>
>>>>>>>> I am just using Bundler, not rvm.  FWIW, this particular test is
>>>>>>>> on FC17.  The error I get is pasted below, the main hint being
>>>>>>>> "cannot load such file -- minitest/unit (LoadError)". This
>>>>>>>> error goes away when I add minitest to the Gemfile and refresh
>>>>>>>> my gems with "bundle install". So, not sure why it is not an
>>>>>>>> issue in rvm (is it doing some extra Gem magic?) but clearly
>>>>>>>> looks to be an issue just using Bundler.
>>>>>>>>
>>>>>>>> $ bundle exec rake cucumber
>>>>>>>> ===== boot.rb will try and use bundler =========
>>>>>>>> ===== application.rb will try and use bundler =========
>>>>>>>> Failed to load /home/prince/w1/conductor/src/config/oauth.json,
>>>>>>>> continuing without OAuth support. Run rake dc:oauth_keys and
>>>>>>>> restart Conductor to enable.
>>>>>>>> /usr/bin/ruby -S bundle exec cucumber  --profile default
>>>>>>>> Using the default profile...
>>>>>>>> ===== boot.rb will try and use bundler =========
>>>>>>>> ===== application.rb will try and use bundler =========
>>>>>>>> DEPRECATION WARNING: Calling set_table_name is deprecated.
>>>>>>>> Please use `self.table_name = 'the_name'` instead. (called from
>>>>>>>> <top (required)> at /home/prince/w1/conductor/src/
>>>>>>>> config/environment.rb:23)
>>>>>>>> Failed to load /home/prince/w1/conductor/src/config/oauth.json,
>>>>>>>> continuing without OAuth support. Run rake dc:oauth_keys and
>>>>>>>> restart Conductor to enable.
>>>>>>>> DEPRECATION WARNING: Calling set_table_name is deprecated.
>>>>>>>> Please use `self.table_name = 'the_name'` instead. (called from
>>>>>>>> <class:Quota> at /home/prince/w1/conductor/src/app
>>>>>>>> /models/quota.rb:37)
>>>>>>>> DEPRECATION WARNING: Calling set_primary_key is deprecated.
>>>>>>>> Please use `self.primary_key = 'the_name'` instead. (called from
>>>>>>>> <class:ViewState> at /home/prince/w1/conductor/s
>>>>>>>> rc/app/models/view_state.rb:33)
>>>>>>>> cannot load such file -- minitest/unit (LoadError)
>>>>>>>> /home/prince/w1/bundler/ruby/1.9.1/gems/activesupport-3.2.3/lib/active_support/dependencies.rb:251:in 
>>>>>>>>
>>>>>>>>
>>>>>>>> `require'
>>>>>>>> /home/prince/w1/bundler/ruby/1.9.1/gems/activesupport-3.2.3/lib/active_support/dependencies.rb:251:in 
>>>>>>>>
>>>>>>>>
>>>>>>>> `block in require'
>>>>>>>> .....
>>>>>>>>
>>>>>>> Actually, after a quick look, it appears minitest is part of 
>>>>>>> ruby 1.9,
>>>>>>> so since you are on f17, I suspect the issue is there. To 
>>>>>>> attempt to
>>>>>>> test this, I spun up a new f17 vm and installed ruby(nothing of 
>>>>>>> ours).
>>>>>>> I then ran:
>>>>>>> $ irb
>>>>>>> irb(main):001:0> require 'minitest/unit'
>>>>>>> LoadError: cannot load such file -- minitest/unit
>>>>>>>
>>>>>>> F17 installs ruby 1.9.3, fwiw, your example shows 1.9.1 - but I 
>>>>>>> dont
>>>>>>> think that is the problem.
>>>>>>>
>>>>>>> Same error, so good indicator there.  I ran the same experiment on
>>>>>>> rvm+ruby 1.9, and the library loaded.  Then I created a new gemset,
>>>>>>> blew away the lock file, and rebuilt it on ruby 1.9 
>>>>>>> (rvm-installed).
>>>>>>> Still no minitest listed there. Then I did a bit of googling, 
>>>>>>> and see
>>>>>>> that minitest is, in fact, part of the 1.9 stdlib[1][2], meaning
>>>>>>> installing ruby should get the library for you. Even the github
>>>>>>> page[3] for minitest says the gem is only needed for ruby 1.8.
>>>>>>>
>>>>>>> Back to f17.  yum search minitest gets me a rubygem. I have more
>>>>>>> searching to do, but I vaguely recall some discussion on ruby-sig
>>>>>>> about splitting out some parts of ruby libraries into separately
>>>>>>> installable rpms, for the purpose of allowing them to be updated
>>>>>>> independently for errata/bugfixes, for example.  I am going to 
>>>>>>> search
>>>>>>> the archive and reply again shortly, but wanted to get this mail 
>>>>>>> out n
>>>>>>> case you are beating your head against it still.
>>>>>>> However, all this still doesn't answer the question of why 
>>>>>>> minitest is
>>>>>>> being required in the first place, or by whom. Grepping for
>>>>>>> 'minitest' in activesupport gem dir returned nothing for me, so 
>>>>>>> think
>>>>>>> that is not the culprit. I also grepped in the specifications
>>>>>>> directory, and found references to it in a number of libraries, but
>>>>>>> they are all listed as developer_dependencies, unless you have a
>>>>>>> version of rubygems < 1.2.0. This is not the case is it?  If 
>>>>>>> not, have
>>>>>>> you made any changes to your Gemfile? I can continue to help debug
>>>>>>> this if needed, ping me later on irc - perhaps I can replicate your
>>>>>>> steps to see where things mught have gone wrong.
>>>>>>>
>>>>>>> -j
>>>>>>>
>>>>>>> [1]
>>>>>>> http://www.rubyinside.com/a-minitestspec-tutorial-elegant-spec-style-testing-that-comes-with-ruby-5354.html 
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> [2]
>>>>>>> http://www.bootspring.com/2010/09/22/minitest-rubys-test-framework/
>>>>>>> [3] https://github.com/seattlerb/minitest
>>>>>>
>>>>>> Jason,
>>>>>>
>>>>>> Yes, I can confirm it is Fedora issue, since Fedora unbundles
>>>>>> minitest out of Ruby, because bundling is wrong. Please add the
>>>>>> minitest into your Gemfile. Since that time, it will work on your
>>>>>> Mac as well as on Fedora.
>>>>>>
>>>>>> BTW minitest is required by activesupport. And you should search for
>>>>>> "test/unit".
>>>>>
>>>>> This is another reason we shouldn't be depending on any of the Fedora
>>>>> ruby stack for upstream development. Rather than "add minitest into
>>>>> your Gemfile," which makes us automatically different from normal
>>>>> upstream Ruby projects, let's "use standard upstream Ruby with RVM."
>>>>> Then it becomes a different team's concern to do the product
>>>>> packaging, which may well include "add minitest into the Cloud Engine
>>>>> Product's Gemfile" and undoubtedly many other distro-specific 
>>>>> changes.
>>>>>
>>>>> For the record, I have no opinion on whether bundling in Fedora
>>>>> packages is wrong or not. I just don't want packaging in between us
>>>>> and success.
>>>>>
>>>>> --Hugh
>>>>>
>>>>
>>>> +1, I meant to reply with something similar, but forgot.  I thin
>>>> adding a dependency in the product (or even fedora) _rpm spec_ is
>>>> fine, but it doesn't belong in the Gemfile.  I have not tested this
>>>> scenario, but I suspect it will 'just work' if done this way, and
>>>> allows fedora/rhel to do what they want afa ruby package structure.
>>>>
>>>> -j
>>>
>>> After I sent this, I remembered I had an f17 vm where I had replicated
>>> the require failure.  I just booted it, installed rubygem-minitest,
>>> and then tries to require 'minitest/unit' (the error line crag got),
>>> and it worked, didn't even require loading rubygems first, so this
>>> further makes me feel any minitest requirement here is a pure
>>> rhel/fedora spec/rpm packaging issue.
>>
>> Firstly, it is interesting, that although you know that adding 
>> minitest into Gemfile would mean that your product would run 
>> everywhere, you will not do that for not apparent reason. It is 
>> interesting, that although the minitest dependency is required, you 
>> don't want to do it explicitly. Moreover, I am pushing upstream to 
>> solve this issue and hopefully one day, it will be done right, i.e. 
>> you will need to add the minitest into your Gemfile anyway. So why 
>> don't do it right now? The benefit to you will be that you know what 
>> are you using and you would be able to use more recent version of 
>> minitest, instead of the one bundled with Ruby.
>>
>>
>> Vit
>
> We have _no_ direct dependency on minitest, it is brought in _through_
> a direct dependency, therefore it does not belong in our Gemfile. If
> anything, bundler should include it in the lock file, and if it did
> that, I would not be opposed.  I can see no reason why a ruby project
> should add specific dependencies for a given OS/distribution who
> happens to have chosen a different way to release versions of things.
> Should the ruby world decide the start using an unbundled version of
> the standard libraries, that is fine, and bundler would get updated
> to reflect those dependencies.  In the meantime, if a platform like
> fedora needs it to be explicit, that should be immediately obvious
> when someone goes to package a gem/project.  Again, we do not
> explicitly depend on this library, so even in the fedora case, that
> dependency would have been resolved in the packaging for the given
> library (think this was active*something that needed it).
>
> -j

BTW this is one of recent commits into Rails: 
https://github.com/rails/rails/commit/6f74d36c4263a6cbbc6dc32a03edeed04faefbd9


Vit



More information about the aeolus-devel mailing list