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