Windows installers and %PATH%
Please have the Windows installers add the Python installation directory to the PATH environment variable. Many newbies dive in without knowing that they must manually add C:\PythonXY to PATH. It's yak shaving, something perfectly automatable that should have been done by the installers way back in Python 1.0. Please also add PYTHONROOT\Scripts. It's where cool things like easy_install.exe are stored. More yak shaving. The only potential downside to this is upsetting users who manage multiple python installations. It's not a problem: they already manually adjust PATH to their liking. Cheers, Andrew Pennebaker www.yellosoft.us
On Fri, Aug 26, 2011 at 2:04 PM, Andrew Pennebaker <andrew.pennebaker@gmail.com> wrote:
Please have the Windows installers add the Python installation directory to the PATH environment variable.
Please read PEP 397: Python Launcher for Windows. Or at least do us the courtesy of acknowledging that if the issue was as simple as "just munge the PATH", it would have been done long ago. Windows is a developer hostile platform unless you completely buy into the Microsoft toolchain, which is not an option for cross-platform projects like Python. It's well within Microsoft's capabilities to create and support a POSIX compatibility layer that allows applications to look and feel like native ones, but they choose not to, since they see cross-platform development as a competitive threat to their desktop dominance. There's a reason many open source projects don't offer native support at all, instead instructing people to use Cygwin as a compatibility layer. It irks me greatly when people place the blame for this situation on volunteer programmers giving them stuff for free instead of where it belongs (i.e. on the multibillion dollar corporation deliberately failing to implement a widely recognised OS interoperability standard). Regards, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Fri, 26 Aug 2011 14:52:07 +1000 Nick Coghlan <ncoghlan@gmail.com> wrote:
We already buy into the MS toolchain since we require Visual Studio (or at least the command-line tools for building, but I suppose anyone doing serious development on Windows would use the GUI). We also maintain the project files by hand instead of using e.g. cmake.
I have a hard time imagining how a POSIX compatibility layer would make Windows apps feel more "native". It's a matter of fact that Unix and Windows systems function differently. I don't know how much of it can be completely hidden.
I wouldn't call POSIX an OS interoperability standard, but an Unix interoperability standard. It exists because there is so much fragmentation in the Unix world. I doubt MS was invited to the party when POSIX specifications were designed. Windows has its own standards, but since MS is basically the sole OS vendor, they are free to dictate them :) And when I look at the various "POSIX" systems we try to support there: http://www.python.org/dev/buildbot/all/waterfall?category=3.x.stable&category=3.x.unstable I have the feeling that perhaps we spend more time trying to work around incompatibilities, special cases and various levels of (in)compliance among POSIX systems, than implementing the Windows-specific code paths of low-level functions (where the APIs are usually well-defined and very stable). Regards Antoine.
On Thu, Aug 25, 2011 at 23:04, Andrew Pennebaker < andrew.pennebaker@gmail.com> wrote:
Please have the Windows installers add the Python installation directory to the PATH environment variable.
The http://bugs.python.org bug tracker is a better place for feature requests like this, of which there have been several over the years. This has become a hotter topic lately with several discussions around the community, and a PEP to provide some similar functionality. I've talked with several educators/trainers around and the lack of a Path installation is the #1 thing that bites their newcomers, and it's an issue that bites them before they've even begun to learn. Many newbies dive in without knowing that they must manually add C:\PythonXY
A clean installation of Python includes no Scripts directory, so I'm not sure we should be polluting the Path with yet-to-exist directories. An approach could be to have packaging optionally add the scripts directory on the installation of a third-party package. The only potential downside to this is upsetting users who manage multiple
python installations. It's not a problem: they already manually adjust PATH to their liking.
"Users who manage multiple python installations" is probably a very, very large number, so we have quite the audience to appease, and it actually is a problem. We should not go halfway on this feature and say "if it doesn't work perfectly, you're back to being on your own". I think the likely case is that any path addition feature will read the path, then offer to replace existing instances or append to the end. I haven't yet done any work on this, but my todo list for 3.3 includes adding some path related features to the installer.
I see that the Ruby 1.9 stable Windows installer has a checkbox to add the Ruby binaries to PATH. That would be excellent for Python. Also, there's no need to "buy in" to the Windows toolchain just to edit PATH. Installer software includes functionality for editing environment variables, and in any case Python has built in environment variable editing, even for Windows. Cheers, Andrew Pennebaker www.yellosoft.us On Fri, Aug 26, 2011 at 9:40 AM, Brian Curtin <brian.curtin@gmail.com>wrote:
On Fri, Aug 26, 2011 at 12:18, Andrew Pennebaker < andrew.pennebaker@gmail.com> wrote:
The built-in environment variable support, e.g., os.getenv/putenv/environ, isn't helpful here as it does not modify the global environment. It modifies the current process and usually subprocesses. The proper way to apply environment variable changes to the entire system is via the registry and broadcasting a setting change message.
I mentioned PYTHONROOT\Script because of the distribute package, which adds PYTHONROOT\Script\easy_install.exe. My mistake if \Script is created by distribute and not Python. Then my beef is with distribute for not adding its binaries to PATH--how else would I use easy_setup if not in a terminal? Cheers, Andrew Pennebaker www.yellosoft.us On Fri, Aug 26, 2011 at 9:40 AM, Brian Curtin <brian.curtin@gmail.com>wrote:
On Fri, Aug 26, 2011 at 2:04 PM, Andrew Pennebaker <andrew.pennebaker@gmail.com> wrote:
Please have the Windows installers add the Python installation directory to the PATH environment variable.
Please read PEP 397: Python Launcher for Windows. Or at least do us the courtesy of acknowledging that if the issue was as simple as "just munge the PATH", it would have been done long ago. Windows is a developer hostile platform unless you completely buy into the Microsoft toolchain, which is not an option for cross-platform projects like Python. It's well within Microsoft's capabilities to create and support a POSIX compatibility layer that allows applications to look and feel like native ones, but they choose not to, since they see cross-platform development as a competitive threat to their desktop dominance. There's a reason many open source projects don't offer native support at all, instead instructing people to use Cygwin as a compatibility layer. It irks me greatly when people place the blame for this situation on volunteer programmers giving them stuff for free instead of where it belongs (i.e. on the multibillion dollar corporation deliberately failing to implement a widely recognised OS interoperability standard). Regards, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Fri, 26 Aug 2011 14:52:07 +1000 Nick Coghlan <ncoghlan@gmail.com> wrote:
We already buy into the MS toolchain since we require Visual Studio (or at least the command-line tools for building, but I suppose anyone doing serious development on Windows would use the GUI). We also maintain the project files by hand instead of using e.g. cmake.
I have a hard time imagining how a POSIX compatibility layer would make Windows apps feel more "native". It's a matter of fact that Unix and Windows systems function differently. I don't know how much of it can be completely hidden.
I wouldn't call POSIX an OS interoperability standard, but an Unix interoperability standard. It exists because there is so much fragmentation in the Unix world. I doubt MS was invited to the party when POSIX specifications were designed. Windows has its own standards, but since MS is basically the sole OS vendor, they are free to dictate them :) And when I look at the various "POSIX" systems we try to support there: http://www.python.org/dev/buildbot/all/waterfall?category=3.x.stable&category=3.x.unstable I have the feeling that perhaps we spend more time trying to work around incompatibilities, special cases and various levels of (in)compliance among POSIX systems, than implementing the Windows-specific code paths of low-level functions (where the APIs are usually well-defined and very stable). Regards Antoine.
On Thu, Aug 25, 2011 at 23:04, Andrew Pennebaker < andrew.pennebaker@gmail.com> wrote:
Please have the Windows installers add the Python installation directory to the PATH environment variable.
The http://bugs.python.org bug tracker is a better place for feature requests like this, of which there have been several over the years. This has become a hotter topic lately with several discussions around the community, and a PEP to provide some similar functionality. I've talked with several educators/trainers around and the lack of a Path installation is the #1 thing that bites their newcomers, and it's an issue that bites them before they've even begun to learn. Many newbies dive in without knowing that they must manually add C:\PythonXY
A clean installation of Python includes no Scripts directory, so I'm not sure we should be polluting the Path with yet-to-exist directories. An approach could be to have packaging optionally add the scripts directory on the installation of a third-party package. The only potential downside to this is upsetting users who manage multiple
python installations. It's not a problem: they already manually adjust PATH to their liking.
"Users who manage multiple python installations" is probably a very, very large number, so we have quite the audience to appease, and it actually is a problem. We should not go halfway on this feature and say "if it doesn't work perfectly, you're back to being on your own". I think the likely case is that any path addition feature will read the path, then offer to replace existing instances or append to the end. I haven't yet done any work on this, but my todo list for 3.3 includes adding some path related features to the installer.
I see that the Ruby 1.9 stable Windows installer has a checkbox to add the Ruby binaries to PATH. That would be excellent for Python. Also, there's no need to "buy in" to the Windows toolchain just to edit PATH. Installer software includes functionality for editing environment variables, and in any case Python has built in environment variable editing, even for Windows. Cheers, Andrew Pennebaker www.yellosoft.us On Fri, Aug 26, 2011 at 9:40 AM, Brian Curtin <brian.curtin@gmail.com>wrote:
On Fri, Aug 26, 2011 at 12:18, Andrew Pennebaker < andrew.pennebaker@gmail.com> wrote:
The built-in environment variable support, e.g., os.getenv/putenv/environ, isn't helpful here as it does not modify the global environment. It modifies the current process and usually subprocesses. The proper way to apply environment variable changes to the entire system is via the registry and broadcasting a setting change message.
I mentioned PYTHONROOT\Script because of the distribute package, which adds PYTHONROOT\Script\easy_install.exe. My mistake if \Script is created by distribute and not Python. Then my beef is with distribute for not adding its binaries to PATH--how else would I use easy_setup if not in a terminal? Cheers, Andrew Pennebaker www.yellosoft.us On Fri, Aug 26, 2011 at 9:40 AM, Brian Curtin <brian.curtin@gmail.com>wrote:
participants (5)
-
Andrew Pennebaker -
Antoine Pitrou -
Brian Curtin -
John O'Connor -
Nick Coghlan