Messed up Perl

[Hal Vaughan]

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 could 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