Fwd: Perl 5.8.8 already present on Leopard; can I make a "dummy" Portfile?

[nicerobot]

King Spook wrote:
> 
> On Sun, Dec 28, 2008 at 10:45 PM, nicerobot
> <com.nabble at nicerobot.org>wrote:
> 
>>
>> To deny this request essentially forces users that have a significant
>> investment in the OS's perl to either spend the time getting macports
>> into
>> the same state and switching to macports' perl
> 
> 
> True, but...
> 1. ...it's a one-off.
> 2. ...I find it preferable to customize MacPort's Perl anyways (not that I
> really have, but if I was going to...) because it's easier to wipe out the
> MacPorts installation than it is to wipe out the OS' installation, and by
> leaving the OS' installation pristine, I'm (more or less) guaranteed it
> will
> be in the expected state for third-party apps.
> 
If i have dozens of utilities i've written that depend on particular modules
being present, i'd definitely _not_ want an easy way to wipe it out.
Personally, i'm not a wipe-and-rebuild person. I like to create environments
that work and modify them as needed. Once a system like that is configured,
it can take hours or days to rebuild it and it can be difficult or at least
more time consuming to ensure it's back to 100%.

King Spook wrote:
> 
> 3. ...how hard is it to duplicate your OS Perl customizations on the
> MacPort's installation?  Exactly how much customizing are we dealing with?
> 
Well, guessing, in my case, i probably use about 20-30 modules but am not
sure about their dependencies nor what was required to build them all.
Again, like my point above, the problem is identifying them. I have the OS
perl configured and working. If i want macports at the front of my $PATH, i
can't use any port that depends on perl without some pain. The only other
option i see is to tarball all the modules in the OS perl's @INC and
shoehorn them into macports' @INC.
I just didn't see a reason to deal with this when it should be relatively
easy to provide the ability to configure macports perl to use the OS perl's
@INC. 

King Spook wrote:
> 
> 
>> or having to decide which
>> perl to use for certain situations and not be able to just rely on the
>> $PATH.
>>
> 
> Why can't you use the $PATH?
> /opt/local/bin at the end -> system perl
> /opt/local/bin at the start -> macports perl
> 
You see my point here. $PATH has to be modified. That is essentially the
same as just fully qualifying the path to the binary i want to use. I mean,
if i need to modify the $PATH to use a single binary under different
situations, it'd actually be easier and safer to just qualify the path to
the binary.

King Spook wrote:
> 
> 
>> Maybe i'm wrong but i
>> thought macports was about providing solution, not creating hurdles.
>>
> 
> Not helping.
> 
> _______________________________________________
> macports-users mailing list
> macports-users at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
> 
> 

-- 
View this message in context: http://www.nabble.com/Perl-5.8.8-already-present-on-Leopard--can-I-make-a-%22dummy%22-Portfile--tp14919531p21201971.html
Sent from the MacPorts - Users mailing list archive at Nabble.com.