Issue #6875 has been updated by vo.x (Vit O.).
kou (Kouhei S.) wrote:
I comment on this issue.
I think that this issue is the right issue for talking about only
test-unit.gemspec. If you want to talk about “default gem”, #5481 is the right
issue. If the latter is true, please use #5481.
Well, yes, it would be probably better to discuss some points there
require "test/unit"
require "./test_xxx"
% ruby test_xxx.rb # -> uses test/unit in StdLib
(same)
% gem install test-unit
% ruby test_xxx.rb # -> uses test-unit gem
(different)
% ruby test_xxx_with_explicit_gem_test-unit.rb # -> uses test-unit gem
(same)
Yes, that make sense. Actually it is one issues I complained in #6124
- The gem usually contains code. It does not depend on some code lying
somewhere in the StdLib
It is right. (.gemspec for test/unit StdLib doesn’t have any problems for
it, doesn’t it?)
StdLib doesn’t, but I cannot package such gem, because it is not gem.
You doesn’t need to package it. It should be included in Ruby’s package itself.
No, that is not true. Not on Fedora and similar guidelines apply to
other distributions as well:
https://fedoraproject.org/wiki/Packaging:Guidelines#Bundling_of_multiple_projects
https://fedoraproject.org/wiki/Packaging:Treatment_Of_Bundled_Libraries
https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries
Actually, see also some comments from Lucas N., who has the same
interest as me, just for Debian.
The “rubygems” means that gem packages on RubyGems.org not RubyGems library
itself, doesn’t it?
If it is true, the change doesn’t depend on additional gem packages.
No I really mean that StdLib should consist from real gems. Since we need them
for packaging and easy updates.
I don’t think that “packaging as RPM” equal to “easy updates”. For example,
users can update by “gem update”. It is also easy update.
You have a view of Ruby developer. Ruby developer is used to use gem
command. But I am defending interest of Fedora users. They don’t really
care about gems, they just want to have their application working and
they want to use system tools to install the application. And in Fedora,
that is RPM/YUM.
In Fedora, we unbundled every gem from StdLib, i.e. the rake is not anymore
part of StdLib. There is no reason to have it in StdLib, since we need only one
version of Rake on system.
There is a reason. We can use rake with “ruby -disable-gems” if rake is part of
StdLib.
See also https://bugs.ruby-lang.org/projects/ruby/wiki/StdlibGem#ToDo . The page
describes advantages and drawbacks.
Yes, you chosen the option 2, while only the option 1 is the correct
approach. What would be the purpose of --disable-gems flag, if you load
gems? If you are using --disable-gems, it is probably for some reason.
If you are using such flag, you should know what are you doing and since
it is not that easy to find it in documentation, you have to be
definitely more experienced Rubyist.
Why “we need only one version of Rake on system”? Is it only for Rake or all
libraries/softwares on Fedora?
Why would you need more versions of Rake? If it is ensured that all the
applications are compatible with the Rake, why would I want to have more
Rakes on my system? How many versions of Rake do you have on your
system?
It applies of course to every library/application.
Fedora has python and python3 packages. Is it not related about “we need only
one version of Rake on system”?
Yes, this is unfortunate exception and you would be able to find more.
But anyway, the ultimate target is to have only one library/application.
It seems that some (or many) Rails users have one or more Rails versions on
system. So I don’t understand “we need only one version of Rake on system”.
Here you are again speaking about Rails developers, not users. Users
don’t care about Rails, but about Redmine or Aeolus, which are build
using Rails.
That is the purpose of RPM and YUM, to manage your packages. It allows easy
updates when new rake version is available as well as it prevents multiple copies
around the system.
Does “multiple copies” means “rake 0.9.2 and rake 0.9.2.2 are on the same
system”?
I don’t think that it is not “multiple copies”…
Yes, this is what I mean by multiple copies.
No for your ‘gem’, since there is no test-unit, just some test-unit shim,
there is no way how to extract it from StdLib. We are already providing in Fedora
full featured rubygem-test-unit, but how it is supposed the original part of
StdLib?
I will not extract it from StdLib.
Yes, because there is nothing to extract. That is the point. In Ruby,
there is currently Minitest and test-unit, which is actually not test
unit. If there would be something to extract into gem, I would already
did it for Fedora.
Feature #6875: Make test/unit default gem
Author: kou (Kouhei S.)
Status: Closed
Priority: Normal
Assignee: sorah (Shota F.)
Category: lib
Target version: 2.0.0
test/unitをdefault gemにするパッチです。
http://bugs.ruby-lang.org/projects/ruby/wiki/StdlibGem
に従ってバージョンは2.0.0.0にしています。
私はtest-unitというgemを作っています。test-unit
gemがインストールされるとバンドルされているtest/unitよりも優先してtest-unit
gemの方が使われると嬉しいのでこのパッチを書きました。