From luislavena at gmail.com Sun Jun 10 00:49:58 2012 From: luislavena at gmail.com (Luis Lavena) Date: Sat, 9 Jun 2012 21:49:58 -0300 Subject: Gem::TestCase, deprecations and building gems during tests Message-ID: Hello folks, I've been working on a RubyGems plugin called gem-compiler which generate binary gems without modifying the gem source code (outside-in): https://github.com/luislavena/gem-compiler This gem is an extraction of a bigger and internal project and I'm slicing it down and aiming to make it a good RubyGems citizen. Part of this task is convert my massive internal specs into tests so I can rely on Gem::TestCase and stay DRY, but I'm a bit overwhelm by all the helpers defined in it. There is quick_gem, util_gem, new_spec, util_build_gem, just to mention a few on different combinations. I'm a bit confused in which will fit better my needs: * Need the path to a real gem file (.gem), it doesn't necessarily needs to be installed. * Need for change specification (platform and extensions). * Need for add real files (extconf.rb or mkrf_conf.rb) inside the gem file. Tried to look into existing RubyGems tests but is not concise which method I should use (some tests are using things that TestCase marks as future deprecation). Hint on where to look at will be much appreciated. Thank you in advance. -- Luis Lavena AREA 17 - Perfection in design is achieved not when there is nothing more to add, but rather when there is nothing more to take away. Antoine de Saint-Exup?ry From steve at steveklabnik.com Tue Jun 12 15:19:08 2012 From: steve at steveklabnik.com (Steve Klabnik) Date: Tue, 12 Jun 2012 11:19:08 -0400 Subject: Gem::TestCase, deprecations and building gems during tests In-Reply-To: References: Message-ID: One of my long-term goals is to work on improving the tests for RubyGems. I only really have knowledge of some parts of the codebase though, so I'm not exactly sure what to tell you, other than that I'd like to learn about this as well. From hgs at dmu.ac.uk Tue Jun 12 16:34:38 2012 From: hgs at dmu.ac.uk (Hugh Sasse) Date: Tue, 12 Jun 2012 17:34:38 +0100 (BST) Subject: Gem::TestCase, deprecations and building gems during tests In-Reply-To: References: Message-ID: Whilst I'm not familiar enough with the structure and many details of Rubygems (as I should be) in order to give you an answer, this re-raises the issue of Software Archeology. My own weak attempt to tackle to this might be of some very limited help in exploring the space. See the code at, and remarks below http://www.tech.dmu.ac.uk/~hgs/ruby/index.html#rdescriber.rb Among other things, this produces diagrams of which classes create instances of which other classes, using GraphViz. The parser is very, very crude. It should probably be rewritten using some of the excellent work from Rubinius, etc. I've not touched the code in a long time, so it is probably frightful, but if it helps, then that's something at least. HTH Hugh From luislavena at gmail.com Thu Jun 14 02:31:36 2012 From: luislavena at gmail.com (Luis Lavena) Date: Wed, 13 Jun 2012 23:31:36 -0300 Subject: Gem::TestCase, deprecations and building gems during tests In-Reply-To: References: Message-ID: Thank you Steve and Hugh, My anxiety won over my laziness so I've spent a lot of hours figuring out how to do what I wanted. So far, I've created my own set of helpers that abstract Gem::TestCase ones for my purpose: * Create a fake gem * Bundle a extension (files) inside the fake gem https://github.com/luislavena/gem-compiler/blob/master/test/rubygems/test_gem_compiler.rb#L90-144 A few things I noticed: new_spec returns the gemspec of the new gem you created, but internally it relocates the gem so you can't use spec.cache_file because that file doesn't exist. I needed to workaround that here: https://github.com/luislavena/gem-compiler/blob/master/test/rubygems/test_gem_compiler.rb#L98 With these helpers, I can: Create a gem and obtain the path to the gem file (cache_file): gem_file = util_bake_gem { |s| s.platform = Gem::Platform::CURRENT } Add a no-op extension to it: gem_file = util_bake_gem { |spec| util_fake_extension spec } Or add a almost-real extension that generates an empty artifact combining above with util_custom_configure helper. One last thing I'm missing is a way to check gem contents and see if I have one particular file inside the generated gem. I guess will have to figure it out ;-) On Tue, Jun 12, 2012 at 1:34 PM, Hugh Sasse wrote: > Whilst I'm not familiar enough with the structure and many details > of Rubygems (as I should be) in order to give you an answer, this > re-raises the issue of Software Archeology. ?My own weak attempt to > tackle to this might be of some very limited help in exploring the > space. ?See the code at, and remarks below > > http://www.tech.dmu.ac.uk/~hgs/ruby/index.html#rdescriber.rb > > Among other things, this produces diagrams of which classes create > instances of which other classes, using GraphViz. ?The parser is > very, very crude. ?It should probably be rewritten using some of the > excellent work from Rubinius, etc. ?I've not touched the code in a > long time, so it is probably frightful, but if it helps, then that's > something at least. > > ? ? ? ?HTH > ? ? ? ?Hugh > _______________________________________________ > RubyGems-Developers mailing list > http://rubyforge.org/projects/rubygems > RubyGems-Developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers -- Luis Lavena AREA 17 - Perfection in design is achieved not when there is nothing more to add, but rather when there is nothing more to take away. Antoine de Saint-Exup?ry