Messed up Perl

[Bradley Giesbrecht]

On Oct 4, 2010, at 8:40 PM, Hal Vaughan wrote:

> First: I don't write diplomatically, so don't take this as personal  
> or as me being angry.  I just tend to be abrupt.
>
>
> On Oct 4, 2010, at 3:30 PM, Daniel J. Luke wrote:
>
>> On Oct 4, 2010, at 3:21 PM, Hal Vaughan wrote:
>>>
>>>> It's entirely reasonable to assume that
>>>> someone who has installed MacPorts wants MacPorts programs to be  
>>>> available
>>>> in their $PATH.
>>>
>>> You've missed a major point: These programs are OVERRIDING what's  
>>> already there.  That's my objection.
>>
>> no, they're not.
>>
>> Those programs are still there.
>
> If I type "cpan" and get the MacPorts version over the OS X one,  
> then, yes, it's being overridden.  The programs may still be there,  
> but they're overridden.  If MacPorts changes my system so the  
> MacPorts version comes before the default for that system, it's  
> overriding it.
>
>>
>>>> If you want to change *where* it is in your $PATH, then
>>>> edit the PATH= line in ~/.profile.
>>>
>>> Yes, I'll be doing that.  My issue there is that MacPorts PREPENDS  
>>> their paths to PATH, instead of APPENDING them, making one use  
>>> MacPorts programs by default, OVER OS X programs that were already  
>>> there and doing just what I wanted them to do.
>>
>> ... your issue is that MacPorts didn't do what you want  
>> automatically.
>
> My issue is that MacPorts AUTOMATICALLY did something I didn't want  
> it to do.  Again, if it had put the system PATH first, then its own,  
> that would be different.  If there is a default on a system, then if  
> that default is changed, it should be made clear, "DEFAULTS ARE  
> CHANGED!"  If there's a warning that PATH is changed, if that change  
> alters the defaults, it's only appropriate to say so.
>
>> Historically, we have done three different things with PATH:
>>
>> 1. Nothing (my preferred solution)
>> - This results in large numbers of "I installed this with MacPorts  
>> and I can't use it" emails to the mailing list
>> 2. Append to the PATH
>> - This results in large numbers of "Why isn't the MacPorts _foo_ I  
>> installed running instead of the system one" emails to the mailing  
>> list
>> 3. Prepend to PATH
>> - This results in a few very angry rants from people who are  
>> confused about what is happening (and usually it seems to be people  
>> running perl who don't realize that there's a difference between / 
>> usr/bin/perl and /opt/local/bin/perl and associated modules).
>>
>> Prepend to PATH seems to enable behavior that most of our users  
>> expect - and it's easy enough for those who want other behavior to  
>> change their own path.
>>
>> If you have a better solution, I'm sure we're happy to hear it.
>
> How about two extra scripts and during the install explain the  
> difference.  You don't have to use strongly technical jargon at  
> first.  You can say, "You have 3 choices: 1) Run this script  
> whenever you want to use MacPorts programs, or 2) Have this  
> automatically set up so MacPorts programs are run easily and have  
> preference over OS X programs, or 3) Have this automatically set so  
> OS X programs are given priority, but MacPorts programs will still  
> run, or 4) Read more technical information before making your  
> choices.  Which is your preference?"
>
> Considering that most users will have some degree of technical  
> experience, trusting them to make a choice on their own system seems  
> a reasonable choice.  I'm curious if that possibility has been  
> discussed.
>
>>> If I run cpan, without prefacing it with "/usr/bin/", I should be  
>>> able to count on it being the default executable, not one that has  
>>> been doctored.
>>
>> It's not a 'doctored' one, it's just that your PATH isn't what you  
>> expect, and you didn't think to look at your PATH or do 'which  
>> cpan' or 'which perl' when things didn't work the way you expected.
>
> "your PATH isn't what you expect..."
>
> That sums it up.  Why SHOULD I look at PATH or run "which cpan"  
> UNTIL or UNLESS I have behavior from my system that isn't what one  
> could reasonably expect?  Here's an example: Tonight is Monday, so  
> I'll put the garbage on the curb along with my recycling because  
> they pick it up on Tuesday.  That's the default and the expected  
> behavior.  Why should I check the city's website on that every  
> Monday when they have stated that's how they work previously?   
> There's no reason I'd check every week to see if they're still  
> picking up trash in my area on Tuesday.
>
> Now, if they are changing, then they're going to announce it to the  
> news stations and sent out mail.  That's how they've done it in the  
> past.  So if there are no announcements made and I've received  
> nothing in the mail, or what I did receive looked like junk mail and  
> not like something from the city, and I have a full trash can  
> stuffed with smelly old food because I cleaned out my refrigerator  
> earlier today, and it sits there all day and I later find, at the  
> end of the day, I have to deal with that smelly stuff all week  
> because NOW they're picking up on Monday and I missed it and there  
> was no announcement telling me the defaults and expected behaviors  
> have changed, I'm going to be ticked off -- and I have a right to be  
> ticked off, since the rug was pulled out from under me.
>
> It's a parallel and not all details work, but changing the default  
> behavior without warning is a bit of an ambush to many people.
>
> And, on that note, I'll say that when I setup MacPorts this time  
> (after a few failed attempts because it never installed Python right  
> if I tried installing packages that depend on it), I installed  
> Python, which got me Python and dependencies.  Then I installed KDE,  
> then Amarok and a few other programs.  In each case, I got a fair  
> amount of warnings from packages about, "Do this or do that."  Well,  
> with all the packages that were installed, many of those warnings  
> scrolled off the screen into oblivion.  So I admit it's possible I  
> got a warning, but since I was not at my computer for the 12+ hours  
> it took to install all the packages, I can't be sure.  I know it  
> sounds like I'm being snarky (sorry, I don't do subtle or diplomatic  
> well and tend to be to the point), but it'd be great if port could  
> keep a list of warnings and actions the user needs to take and  
> report them all at the end of the install as well.  Just piping them  
> to a temp file as well as putting them on the console c
> ould do that.  Then it'd be much easier to be sure one gets all the  
> needed warnings.
>
>>> As best I can remember, at no place, when installing anything, did  
>>> MacPorts warn me, "Hey, guy, we're usurping your defaults by  
>>> putting our path BEFORE yours, so you'll always run our stuff over  
>>> the defaults now."
>>
>> I haven't installed from the .dmg installer in a long time, but it  
>> should probably mention this. It would be super-awesome if you  
>> would contribute to the community of volunteers who make MacPorts  
>> happen if you could submit bug reports like this last sentence to  
>> our bug tracker (and even better if you feel motivated enough to  
>> figure out how to fix the problem and submit the fix as well).
>
> I don't mind submitting bug reports, but I do want to know, openly  
> and honestly, how they're handled.  I am essentially retired now  
> (but found a way to do very well if I spend a few months returning  
> to programming).  I ran my own business based on my own software and  
> did well with it.  (The first time I published a program for my  
> clients was the first time I had ever written a program for others  
> to use -- in 18 months there were less than 6 bug reports!)  I use  
> FOSS and support FOSS and have even written or contributed to some  
> FOSS programs (one was IzPack, an installer in Java, and one is for  
> LinuxICE, where I wrote a controller to control an HD radio through  
> a serial port in Linux).  While there are languages I'm clueless in  
> and I'm self taught, I can deal with programming.
>
> But I've had bad experiences with some FOSS projects when I filed  
> bug reports.  I've gotten things like, "It's a feature, not a  
> bug" (when I could demonstrate why it was NOT a feature) and had  
> some other bad experiences when reporting bugs on FOSS programs.   
> Because of that, I've been slow to file other bug reports.  I can  
> give technical descriptions and help with bug reports and feature  
> requests, but it helps to know if a project and the people in it  
> really do want those reports and don't want to just close them out  
> in a hurry or rationalize them away.

Hal, so many words for a small issue. Decisions were made with the  
intent of serving the most people the way they expected to be served.  
There are but a handful of people trying to serve you here. Either  
contribute or not, up to you, but please just fix your PATH the way  
you like and let us move on.

Brad