> ... your issue is that MacPorts didn't do what you want automatically. > > 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.
So it basically sounds like, If I install X via macports, I want to use macports X and not system X. Otherwise, I want to use system Y, and the macports programs specify the macports Y. So, for any program with a local version and a system version, we need a generic_select program. So the first question is, how does python_select work, and can we make a generic_select? And note that this doesn't quite address the issue of "User 1 installs the newest perl for their use, but user 2 wants the older, system perl". But we must have run into that with python already -- how do python users deal with multiple users on a system wanting different versions? -- Political and economic blog of a strict constitutionalist http://StrictConstitution.BlogSpot.com _______________________________________________ macports-users mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
