On 8/24/06, Paul Guyot <pguyot <at> kallisys.net> wrote:
>
> Le 24 août 06 à 16:16, jeanpierre <at> gmail.com a écrit :
>
> > On 8/23/06, Tim Pritlove <tim <at> ccc.de> wrote:

[snip]
> > the end goal is to install rails, no? even if it isn't, i would
> > recommend james duncan davidson's "Sandboxing Rails with Darwin Ports"
> > article:
> >       <http://duncandavidson.com/essay/2006/04/portsandbox>
>
> You shouldn't do this.
>
> Instead, do:
> sudo port install rb-rails

hmm, and when another security issue occurs with rails like the recent
1.1.5 & 1.1.6 excitement, we can just cross our fingers and hope the
rails port maintainer is paying attention that evening, updates the
port, pushes it to the server all super quickly for us to sync and
update? perhaps that was the case this go around, but in general it
seems unnecessarily fragile - why add another level of indirection,
another level to introduce new errors and delays?

[snip]
> > it seems a little strange to have a macport for every ruby gem though
> > doesn't it - how meta.
>
> I disagree. We should have a macport for every ruby gem and you
> should use them.
> For two reasons:
> #1 using gem will pollute /opt/local

for those that point their prefix to /usr/local it would seem
perfectly normal to install items into it that didn't originate from
macports no - why should /opt/local be any different?

what is the real problem here? upgrading the ruby port would cause an
avalanche of errors since RubyGems may have added files/directories
into the ruby port's directories? if so, maybe port needs to be more
intelligent to better handle situations like that?

> #2 using MacPorts allow you to safely remove gems.

RubyGems seems fairly capable of removing gems as well. while it
certainly leaves quite a lot to be desired, the fact that it is well
supported in the ruby community and the infrastructure is up to date
(and it is easy to install via source) is quite a win.

> Besides, as I explained recently here, it's extremely simple to build
> a portfile for a gem with the recent addition of the gem option for
> the ruby PortGroup.

while perhaps simple, it isn't particularly scalable/maintainable is
it? for the average developer, what is the real incentive to
naturalize gems into ports? so that port doesn't choke on unknown
files? to better support upgrading?

is macports really going to offer a mirror world of
gem/cpan/pear/xyzzy? that seems like a whole lot of effort to
constantly lag behind. maybe if there were a dynamically generated
port that was created by the gem command -but then you'd never get
hashes…

regards,
jean-pierre