On 30 Mar 2010, at 22:16, Lucas Nussbaum wrote: > On 25/03/10 at 14:46 +0000, James Tucker wrote: > >> So after another hairy discussion on various lists, IRC channels and what >> not, I'm getting the urge to try and fix this for reals this time around. In >> an effort to do this, I'm dropping the ever so popular agile approach. This >> is a platform heavy issue, so I need better specs about platform specific >> requirements. That requires input from you guys, and from anyone else in a >> similar position. Spec collection is to happen on this wiki page, and I've >> started a small template of the discussion already. My lunch hour is coming >> to an end though, so there's plenty more to be added. Please add your >> opinions, requirements, design level bugs and so on, and I'll do what I can >> to distill this all down into a set of requirements that I can produce >> patches against. >> >> http://wiki.github.com/jbarnette/rubygems/packaging-designs >> >> As a sort of aside, I'm doing this to fix these problems as best as >> possible, and as such, I'm simply going to ignore any flame war that starts. >> The only way to move forward is to understand, and that's my intention, so >> please, I implore you all, explain your position clearly, rather than making >> demands, and whatever history you have is unimportant now, we're moving >> forward. >> >> If you know other maintainers that were not included in this email, please >> do forward this on to them, I need as much info as possible about what >> peoples requirements are in order to satisfy as many of them as possible in >> as few patches as possible. >> >> The final stages of this process should result in: >> >> * Fresh documentation for teams packaging rubygems and gems inside other >> package managers >> * A set of platform test infrastructure wired to build / commit / gem push >> hooks allowing us to be more proactive about these issues in future (the >> SUSE team have some great tools here, and a lot of domain knowledge already) >> * An agreeable attitude and platform for open discussion of these issues >> >> A quick word of warning about expectations. I'm not looking to move really >> fast on this. We need to get it right, and we need to avoid adding bugs as >> we do it, that's going to require /real/ and /extensive/ manual testing and >> a mature approach. Expecting fixes next month is not the intention here. >> What I do expect is that we can have standard ways to get this stuff off the >> ground, and reduce support requests for all related projects, with releases >> in most of your platforms hopefully by next year. > > So, to start things off, I'll clarify what we do in Debian. We do not > package gems (as in: libraries distributed as .gem files, for > installation with rubygems). > > Instead, we package ruby libraries. Usually, this is done by using the > .tgz provided by the upstream developers (the library's developers), or > using a service that allows us to fetch a specific tag from github as a > .tgz.
That's ok for some packages, but absolutely not ok for others. > However, we provide a rubygems package in Debian, for users who want to > install gems manually. Yup. > So, our interest in this discussion is (in no particular order): > - to improve the rubygems package where possible, thus improving the > user experience for its users [ I'm not directly involved in the > rubygems packaging, but [email protected] (Cced) is ] RubyGems is actually integral to ruby now, and as such, in many ways it should no longer be separated. I think a more sane way to look at this is that Ruby + RubyGems is a single platform, and it's heading that way, especially with gem_prelude in 1.9. I would like to get to the point where we have sufficient support and infrastructure that this merge is no longer a point of contention. I think if you'll bear with me, I can manage that too. > - to improve the awareness of our needs in the rubygems community You need to inform me, on this round, primarily, as this will be the largest push in this direction to date, and provided we can keep discussion moving forward in a sane way, I will succeed. This is also why I have put a 1 year timescale on my approach. > Our need (and major cause of annoyance) is that libraries developers > should provide their code in a rubygems-agnostic way, which means: This is unacceptable. Let me explain: RubyGems is a package manager, yes, but it is also a library, and a dependency manager. The difference between a package manager and a dependency manager is this: * A package manager manages out-of-process build time resource dependencies * A dependency manager manages a build, load, and runtime set of runtime dependencies For packages that exclusively use rubygems as a package manager, you would be fair to ask people to be agnostic, and indeed, in those cases it is easy. Packages that use rubygems as a library or as a dependency manager on the other hand, is a different story entirely. The call to Kernel#gem that occurs in binfiles for one example, will activate dependencies of the gem being loaded, and setup a runtime dependency tree making it possible (and implicitly configured) to load specific versions of other libraries that are needed, at runtime. Repackaging outside of rubygems removes features such as this, and also removes plugin features, platform configuration details (Gem.ruby, etc), and other extremely useful conveniences for the developer. One might claim that this is contrary to the unix philosophy of single purpose tools, and indeed, in some ways you would be correct, however, RubyGems is not a unix tool for stream processing, it's a platform tool, for helping people operate in a platform agnostic way. > - library distributed as a .tgz file in addition to a .gem file Due to the above reasons and many more, this is not possible for a large number of projects, and I don't think it is the right integration point for us anyway, as I believe I can provide better options than this. > - standard (setup.rb-like) file layout, so we can simply use setup.rb to > install the files You shouldn't be doing this, last time I checked setup.rb was GPLv2. Besides the obvious licensing issues, which I know matters to Debian, there are other significant issues with the approach of installing into site_ruby, which is another exact reason why RubyGems being used is so important: Imagine two libraries, both have a file with an event.rb file: cat lib1/lib/event.rb class Event; end cat lib2/lib/event.rb module Lib2::Event; end Now, lets say I install lib1, then lib2, in that order, using a setup.rb approach. In my runtime, I require lib1, and this is what happens: require 'event' # works class Blah; ....; end # all works Blah.new.go # => uninitialized constant Event (NameError) This is unavoidable using a setup.rb approach, and in fact, the above error is caused by this repackaging approach. It can also occur within rubygems itself, iff both libraries are activated at the same time, indeed, I patched the "aasm" gem for this violation some months ago. Like I say though, the problem is unavoidable with your approach, however, when used correctly by users, RubyGems provides a very powerful set of ways around these problems, by nature of being a runtime dependency manager that manages the $LOAD_PATH for the user from a well specified developer manifest (the gemspec). > - no "require 'rubygems'" in the code That's fine, however, that doesn't mean the project doesn't depend on RubGems, and more than that, it is expected to be part of the standard library as of Ruby 1.9. (Although this statement is also supposed to be unnecessary on 1.9 due to gem_prelude.rb). > - preferably no "require 'rubygems'" in the Rakefile or in the tests, to > make it possible/easier to run the test suite at package build time As above for the most part. > -- > | Lucas Nussbaum > | [email protected] http://www.lucas-nussbaum.net/ | > | jabber: [email protected] GPG: 1024D/023B3F4F | _______________________________________________ Rubygems-developers mailing list http://rubyforge.org/projects/rubygems [email protected] http://rubyforge.org/mailman/listinfo/rubygems-developers
