ruby_select plan, rubygem: dependency operator

[Ryan Schmidt]

On Apr 15, 2009, at 07:07, C. Florian Ebeling wrote:

> On Wed, Apr 15, 2009 at 12:16 PM, Ryan Schmidt wrote:
>
>> On Apr 15, 2009, at 04:35, C. Florian Ebeling wrote:
>>
>>> On Wed, Apr 15, 2009 at 11:19 AM, Ryan Schmidt wrote:
>>>
>>>> On Apr 15, 2009, at 03:03, C. Florian Ebeling wrote:
>>>>
>>>>> A ruby port also consists of only 3 or 4 lines of effective  
>>>>> code, if you
>>>>> use the ruby.setup call from the ruby group file. What worries me
>>>>> more is the brittleness when you just can pull away dependencies
>>>>> using the special package manager, gem in the ruby case.
>>>>
>>>> Yes, it would be good to fix it so that users cannot cause that  
>>>> problem.
>>>
>>> I don't see what the correct behaviour is, when having a port  
>>> that wraps
>>> over a gem, for instance. When the gem is loadable as ruby  
>>> library, then
>>> it is visible to the gem manager, and can be removed as well.  
>>> Even if
>>> there was a way to make a gem visible but not manipulatable, that  
>>> would
>>> be very strange behaviour from a ruby/gem perspective.
>>>
>>> So I suggest not trying to stay in control here, but rather act  
>>> like for
>>> other dependencies for which we don't exert control (path, lib).
>>>
>>> Or do you have an idea how to really fix this problem?
>>
>> How does the perl5 portgroup handle it? Is it using CPAN to  
>> install the
>> modules, and can they then be uninstalled or upgraded by the user  
>> by using
>> the cpan command?
>>
>> For the pecl portgroup I'm working on, which will be based on the  
>> existing
>> php5-* module ports, we do not use the pear command to install, so  
>> the user
>> will hopefully not be able to use pear to upgrade or uninstall  
>> either.
>
> That is an approach that is certainly not acceptable for the
> ruby community. There is really virbrant exchange and reuse
> of gems over platforms like GutHub these days, and gem
> comes as part of the standard ruby release. All these ruby
> people would just walk away from MacPorts if where to try
> and shut down use of gem for them.
>
> I don't know if there is a way to make gems install in a
> different location from port, and still have it visible from
> ruby loading point of view. But I am pretty sure that view
> is identical with the one gem sees in general, by virtue
> of being a plain ruby script. Because of we made ruby
> scripts require to add to the load path to see gems from
> mp that would defy the effort.
>
>>
>> Maybe it is simply a user error to use gem or cpan to manipulate  
>> those
>> packages, and users just need to be educated to use MacPorts for all
>> software installations.
>
> I agree, at the moment it is. But I think we could do a better job  
> there.
> Maybe these rubygems dependencies could even be installed without
> a portfile and right through the special installer. Or that is too  
> ambitious
> and port should just fail and explain the missing dependency and show
> the command to bring them into place. I don't know.
>
> But the current situation is not really ideal. I understand your  
> reluctance
> to introduce very high-level dependency operators/types, because  
> normally
> MacPorts shouldn't have such a notion as "rubygem." But what are
> better alternatives. As said, I find the "This is a user error"  
> view not
> too compelling (still it would involve the least work - we have it ;)

Find a way to install the gem in a MacPorts port that does not cause  
the gem to show up when a user runs "gem". Build this into the ruby  
portgroup. Maybe we need to have a patched version of gem that we  
use. Maybe we need to not use gem at all to install.