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.
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
