Feature #9852: How to bundle test-unit2 and minitest5

• Status: Closed
• Assignee: kou (Kouhei Sutou)
• Target version: 2.2.0

[hsbt (Hiroshi SHIBATA)]

I removed test-unit and minitest at #9711
But we need to bundle testing framework with Ruby 2.2.0 continuously.

I hope to bundle test-unit2 and minitest5 with Ruby 2.2.0.

kou
Could you bundle and maintain test-unit2 on CRuby?

ryan
Do you have any idea of gem installation mechanism with packaging?

[zenspider (Ryan Davis)]

Rubygems allows for installation from local gems, so it'd be entirely possible to have the gems contained in the tarball in a directory, and installed normally. It shouldn't be too much work to make this happen only during packaging time (ie, we don't need to commit the gem binaries to SVN, just a manifest of what gems/versions we want). I would like this to happen for all of the gems we currently ship internally: rake, minitest, rdoc, etc. Authors, willing, of course.

I don't know the build system very well, so I don't know all the places I'd have to poke at to make this happen. Suggestions/patches welcome.

I also have the ruby gem. We can use that as a meta-gem that simply declares fixed dependencies on all the gems that ship with that version. If a user wants to repair their setup, they'd only need to run gem install ruby -v x.y.z.

[kou (Kouhei Sutou)]

Hiroshi SHIBATA wrote:

I hope to bundle test-unit2 and minitest5 with Ruby 2.2.0.

Could you explain why you want to bundle test-unit2? It is for providing test-unit API. Right?

(test-unit API means that API provided by test-unit bundled in Ruby 1.8.)

If you expect that test-unit2 provides 100% compatible test-unit API, unfortunately it is wrong. test-unit2 has some incompatible API changes. For example, the following test suite shows different behavior:

require "test/unit"

class Parent < Test::Unit::TestCase
  def test_parent
    p :parent
  end

  class Child < self
    def test_child
      p :child
    end
  end
end

test-unit API (= test-unit gem 1.2.3) runs tests defined in parent test cases:

% ruby a.rb
Loaded suite a
Started
:parent
.:child
.:parent
.
Finished in 0.000207854 seconds.

3 tests, 0 assertions, 0 failures, 0 errors

test-unit2 doesn't run tests defined in parent test cases:

% ruby a.rb
Loaded suite a
Started
:parent
.:child
.

Finished in 0.001269378 seconds.

2 tests, 0 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications
100% passed

1575.57 tests/s, 0.00 assertions/s

I think that the current test-unit2 behavior is better to write organized tests but it is not suitable for 100% compatible test-unit API expectation.

So I want you to explain why you want to bundle test-unit2.

kou
Could you bundle and maintain test-unit2 on CRuby?

Yes with reservations. If bundling test-unit2 satisfies your expectation and it doesn't break integratioin with test-unit2 released at RubyGems.org(*), I say yes.

(*) Users couldn't use test-unit2 gem by gem install test-unit. Users also need to call gem "test-unit" in their code. It was solved by introducing default gem feature. I don't care about mechanism. It is OK to me that it is solved by other mechanism.

[hsbt (Hiroshi SHIBATA)]

• File gem-install-task.patch added
• File gem-install-task.patch added

I implemented gem install task when running with "make install".
This task detect gems from gems directory and install it.

[hsbt (Hiroshi SHIBATA)]

• File deleted (gem-install-task.patch)

[hsbt (Hiroshi SHIBATA)]

• File deleted (gem-install-task.patch)

[hsbt (Hiroshi SHIBATA)]

• File gem-install-task.patch added

[hsbt (Hiroshi SHIBATA)]

redmine can't handle my attachments file.
Please see https://github.com/hsbt/ruby/compare/ruby:trunk...bundle-gem

[zenspider (Ryan Davis)]

I don't think we need to actually commit the gem files to SVN, but I think your patch is a good start.

We could have a manifest of the gems & versions we want to package and have that be part of the packaging and/or compiling step. With exact versions specified, we won't need to keep updating "large" binaries in version control.

[hsbt (Hiroshi SHIBATA)]

I updated my patch. this patch downloads gems defined in gems/bundle_gems when package making time.

[hsbt (Hiroshi SHIBATA)]

• Status changed from Open to Closed
• % Done changed from 0 to 100

Applied in changeset r46536.

---

• tool/make-snapshot: download bundle gems when package making.
  [Feature #9852][ruby-core:62676]
• gems/bundled_gems: listed bundled gems for Ruby 2.2.

[zenspider (Ryan Davis)]

May I convert rake & others?

[zenspider (Ryan Davis)]

Also, does this not hook into make install?

[akr (Akira Tanaka)]

Please don't make network accessibility mandatory for "make install".

1. It makes difficult to develop Ruby when PC is not network accessible.
2. It makes difficult to distinguish (temporal) network failure or other problem in CI.

[zenspider (Ryan Davis)]

There needs to be SOME step that a user can take to get a full install. svn co ...; autoconf ; configure ; make install is still our default path and should wind up with the same thing you'd get from a build from make dist.

I'm sure we can add a new make rule for non-networked development.

[vo.x (Vit Ondruch)]

I always had the vision that the gems should be available in source format. Something like svn:externals or git submodules. The sources would be editable that way, which comes handy at some times. It also avoids the "download" step, since it would be done directly with repository checkout.

[naruse (Yui NARUSE)]

• File deleted (gem-install-task.patch)

[vo.x (Vit Ondruch)]

• Related to Bug #10610: "make install" fails without zlib added