On Wed, Apr 15, 2009 at 12:16 PM, Ryan Schmidt <[email protected]> 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 [email protected] _______________________________________________ macports-dev mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
