[ruby-core:31231] Re: [Bug #3140] gem activation has changed between 1.8 and 1.9

On 12 Jul 2010, at 19:47, Yukihiro Matsumoto wrote:

> Hi,
> 
> In message "Re: [ruby-core:31215] [Bug #3140] gem activation has changed between 1.8 and 1.9"
>    on Tue, 13 Jul 2010 02:51:04 +0900, Yehuda Katz <[e-mail]> writes:
> 
> |Bottom line: I cannot personally support a version of Ruby that can silently require a dependency that is explicitly disallowed by the parent. That possibility is ridiculous, and I'm amazed that, for months, it has been downplayed.
> |
> |If the problem is that ruby-core doesn't use RubyGems that much, and isn't willing to avoid breaking fundamental package manager properties, perhaps it's worth reconsidering including it in Ruby 1.9.
> 
> I am sorry that I haven't followed this issue.  As far as I
> understand, this is caused by unfortunate timing.  Eric was busy at
> the critical timing, most of us hesitated modifying it without Eric's
> concent, and passing the maintainer role to Evan was late.

In a way I agree that the timing on this specific ticket has been unfortunate, but the issue in question here, and other issues have existed ever since gem_prelude.rb was integrated.

Evans patches add a single viable (hack) to workaround the issue, but they do not remove secondary gem_prelude.rb issues.

Just for the sake of making sure that there is awareness, I am going to detail some more experiences here:

6 months ago I was helping a friend of mine try to debug issues in an app written to perform some very simple serving of xml processed through xslt. Something ruby, rack, and thin/cgi are very capable of. The user eventually dropped using ruby for the project after she realised that the bug I tracked down I was only able to track down because I'm intimately familiar with all of these projects and with rubygems and the gem_prelude.rb issues. To her, as a non-rubyist this was totally unacceptable, and she subsequently rewrote what she needed in C, and will not be using ruby in the foreseeable future. This is not an uncommon story, most users wouldn't even get an answer as to the source of their issues. Arguably such a user should not have been using 1.9, however, that seemed like a good idea to her, due to the presentation in her OS package manager. Documentation immediately available did not direct her otherwise.

We have had numerous complaints in #rubygems regarding issues introduced by gem_prelude, and whilst I won't speak for the other committers, this does take away from support time provided to users with other problems, and reduces time I spend patching.

The same is true for Rack.

The same is true for EventMachine.

There's also a clobber that is absolutely horrible between older versions of 'aasm' and 'state_machine' that 1.9.x makes almost impossible for users to solve correctly at this time. This is just yet another example. I could provide a full audit of similar clobbers soon once I've finished updating my gem mirror and gauntlet code. Such a thing won't actually solve anything though.

If you 'gem install mongrel' on 1.9, it will fail (for a valid reason). The directory is not removed because that would prevent users from debugging the build process by reading 'gem_make.out' that is left there for this purpose. gem_prelude.rb is unaware of this, and will allow "require 'mongrel'" to pass, resulting in an exception that to end users is totally cryptic (it will fail on http11.so, which won't exist). The cause of this odd error, and indeed "require 'mongrel'" even trying to load is the fault of gem_prelude. I've seen bug reports to rubygems about this issue to, but we do not really have control over prelude (although I fixed some bugs in it a while back regarding ConfigMap, the sync had to be done by a person with commit on ruby-core, honestly, I don't know if that even happened, but it wasn't a blocker for me).

There is also of course the major bug that Yehuda has pointed out.

There are bugs also in any gem that uses other facets of the rubygems api, where gem_prelude is incomplete or lacking (the ConfigMap example which I fixed only being one example).

Whilst I appreciate that Eric has a very laid back attitude deferring to ruby-cores desires on the matter, I say as I know many others do here, that gem_prelude.rb is insufficient as a replacement for RubyGems. More than this, short of *really* embedding RubyGems, I really can't see all of the issues being solved with any level of completeness - to do so would fundamentally require that gem_prelude.rb passes both all of rubygems test cases, and in-the-wild use case coverage that we don't even have in tests. RubyGems is not "bloated" at what it does, honestly, take a look at the code base, it's short enough to really grok in a few hours. Pretending that 300 lines of code can replace all of its domain expertise is not really reasonable, IMO.

I don't mean to sound like RubyGems is the be-all and end-all of packaging, even for ruby, I know that it is not - however, a broken partial reimplementation has been proven in 1.9 to be dire for a great deal of projects, and there are plenty of in-the-wild examples of this. Those examples will only become more and more frequent when ruby 192 is touted as a "production ready release", and the overall impact could be quite disastrous in reality. People already vested in ruby will not move away, more than likely, but they will pass around hacks to solve the problems, or rvm will begin to carry unofficial patches, or many other possible workarounds. Newcomers or opposers to the language will simply have total fuel for their fire however. I'm not being sensationalist, this is already happening, and I'm not the only one to have seen it. 

Here is another from Rack that I cleared *today*: http://github.com/rack/rack/issues/closed#issue/35/comment/308670 Of course this is just a repetition of the bug demonstrated by Yehuda that is critical for bundler and rails 3.

Yehuda has said that he cannot support a release that has this issue, I will go further as to say that personally, I will state to anyone that asks, that any release of ruby that still contains this abomination is specifically not production ready. I say this because it will continually add support load for *at least* three of the projects that I commit on, that cover between all of them, some of the well used ones in our community outside of (and including, by dependency) rails. The most effective way for me to get that time back is to push a culture that rejects versions that will still bring up these issues. This would be a purely preventative measure!

Yes some of the content of this mail is heartfelt. I trust that you will recognise that there is reason (read: pain) behind that. If it made this mail read badly, I can only apologise for that part.

I do hope that this provides some more of an idea of the issues behind this, and why some of us feel so strongly about it. It is also why I sent a tweet to you on the topic a few weeks ago.

Evan did ask me not to push this issue for 192, so that the release can happen, and I have conceded that the more "minor" issues (that are not blockers to rails) can be ignored /for this release/, however I am still deeply unhappy about this as there will still be support load induced by the inherent bugs in the gem_prelude.rb approach detailed above. That is the only reason I am writing this mail. I am still ok for 1.9.2 to go ahead in such a way that prelude may have some issues, provided it doesn't block rails (i.e. with Evans patch plus whatever is required for stability).

I would however like to see this resolved for 1.9.3, and I am working on patches to rubygems that should make inclusion of rubygems.rb viable for 1.9.3, rather than using the gem_prelude.rb hack. There is one requirement I know of - the 0 stack requirement - that I may not meet, but I think this will have to be conceded for the sake of the worlds sanity. This part should obviously be discussed elsewhere, for 1.9.3.

Apologies once again, if any of this comes across as a rant, but it's important that awareness is there, particularly that the rails issue is not the only one.

> I think 1.9.2 should run Rails3.  If I understand what Yehuda told me
> correctly, this issue could be a show stopper.  I know RC2 is so late
> to add a change, but loosing Rails3 people is critical for 1.9.2
> popularity.  I don't want to see 1.8.6 tragedy again.  It took us
> years to overcome slight incompatibility with ActiveSupport.  Don't be
> bureaucratic.
> 
> 							matz.
>