ruby_select plan, rubygem: dependency operator

[C. Florian Ebeling]

On Wed, Apr 15, 2009 at 12:16 PM, Ryan Schmidt <ryandesign at macports.org> 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 ;)





-- 
Florian Ebeling
Twitter: febeling
florian.ebeling at gmail.com