This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: Rename Scripts directory to bin and move python.exe to bin
Type: enhancement Stage: needs patch
Components: Build, Installation, Windows Versions: Python 3.5
Status: open Resolution:
Dependencies: Superseder:
Assigned To: brian.curtin Nosy List: VanL, brian.curtin, eric.araujo, ezio.melotti, giampaolo.rodola, ishimoto, jpe, loewis, mdengler, mhammond, steve.dower, tim.golden, v+python, zach.ware
Priority: high Keywords:

Created on 2012-03-14 16:29 by brian.curtin, last changed 2022-04-11 14:57 by admin.

Messages (19)
msg155762 - (view) Author: Brian Curtin (brian.curtin) * (Python committer) Date: 2012-03-14 16:29
After talks at PyCon with several people, python.exe will live in C:\Python33\bin rather than C:\Python33 to come more in line with the Unix layout.

This will also simplify another issue with the Path option for the 3.3 installer as well as packaging's target directory for top-level scripts (used to be Scripts/, will be bin/).
msg156097 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2012-03-16 23:06
IIUC this is about two changes:
- Moving python.exe to the scripts subdirectory instead of the top-level install dir
- Renaming that subdir from Scripts to bin

The first change will reduce the number of dirs to add to PATH from two to one, which sounds nice; the second is more controversial, as shown by the current python-dev discussion.

I am also not sure of the risks if we make an exception to the distutils freeze.
msg156102 - (view) Author: Brian Curtin (brian.curtin) * (Python committer) Date: 2012-03-16 23:22
If that thread ever comes to a conclusion, can someone summarize it here?

Also, is there a reason distutils even matters here?
msg156113 - (view) Author: Mark Hammond (mhammond) * (Python committer) Date: 2012-03-17 00:48
To clarify the second comment from Eric: it is actually the first of the proposals that I consider controversial - moving where python.exe lives (regardless of to where) will break 3rd party tools.  If a decision was made to move it anyway, then renaming "Scripts" to "bin" and installing it there makes sense IMO.
msg156115 - (view) Author: Brian Curtin (brian.curtin) * (Python committer) Date: 2012-03-17 00:55
It'll break tools who just look for "C:\\Python%d%d\python.exe" % (x, y) or some variation, but that's not a very dependable solution. If you're using the registry to find actual install locations, I think you'll be alright.

What other solutions for finding python.exe would break by moving the location?
msg156117 - (view) Author: Mark Hammond (mhammond) * (Python committer) Date: 2012-03-17 01:06
Tools that use the registry will typically look up the InstallPath key and look for python.exe there.  They will not look in sub-directories (except some may look in PCBuild and PCBuild/amd64).  It is exactly those tools I'm concerned about.
msg156118 - (view) Author: Brian Curtin (brian.curtin) * (Python committer) Date: 2012-03-17 01:12
A suggested solution to that was to add BinaryPath to give them the proper path.

We could potentially expose BinaryPath in older installers, just pointing at the same value as InstallPath. It's an installer-only change and very low (no?) risk, just preparing users as they move forward.
msg156149 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2012-03-17 10:03
I'm still in favor of the change, accepting any breakage that will result from it.
msg156309 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2012-03-19 03:20
After more discussion, it appears that this change is too incompatible to be done in a single release.

Therefore, I propose a long-term change into this direction, with the actual change not happening until 3.5.

For the change of the python.exe location, I propose to add a key to the registry, say, "BinaryDir", which is added to 3.3 and later. Adding it to older installers is not useful, IMO, since people still need to implement a fallback logic. In 3.3 and 3.4, this will point to the toplevel directory, and in 3.5, it will point to the bin/scripts directory.

Now, for the change from scipts to bin, I don't have any good solution. Proposals, in particular including registry keys, are welcome. Symlinks are out as they require admin privileges. Testing for the presence of some directory might be an acceptable solution.
msg156410 - (view) Author: VanL (VanL) Date: 2012-03-20 14:24
As Éric mentioned, there are two proposals here:

1. Move the python exe
2. Change 'Scripts' to 'bin'

As for #1, what about letting the location of the python binary be an install option:

[ ] Put python.exe into binaries directory and add to PATH?

And then make it unchecked by default in 3.3, checked by default in 3.4, and then remove the option for 3.5?

As for #2, I don't see a lot of resistance; the issues seem to mostly be with #1. Could #2 move into 3.3?
msg156425 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2012-03-20 15:57
I'm still opposed to having the path manipulated by default, but Brian is working on a patch to edit the path with the default being off. If python.exe stays in the toplevel directory, it means that two entries have to be added to the path, making it even more messy and bloated than path editing already is. So I still think that it should be all in bin in the long term.

Anybody opposed to changing scripts to bin please speak up; I'm happy to change it for the next alpha release, and let people object here in this issue (with the potential of reverting the change if there is too much opposition).
msg156437 - (view) Author: Glenn Linderman (v+python) * Date: 2012-03-20 17:17
msg156410 sounds good to me... +1

If the conversion is optional in 3.3, that would seem to solve the problem; if BinaryDir is added, people can use that for 3.3; if people want to use software that hasn't migrated yet, they choose the default path of least resistance, leaving things where they are but with BinaryDir pointing there.

PATH manipulations would be simpler, being a single PATH entry, so tying that to choosing the non-default option seems practical.

This would allow people that don't need the compatibility with installers that don't understand the new structure, to continue to function, gives the installer people a test bed if they don't get things done by the time 3.3 ships, gives people that prefer the consistency across platform structures the ability to have it, as long as they don't need the intsaller... in short, one question at install time could allow us to have our cake and eat it too!

Clearly the launcher may need some adjustments for this, but BinaryDir should suffice to help it do the right thing for both types of installation.
msg156457 - (view) Author: John Ehresman (jpe) * Date: 2012-03-20 20:33
Just a few thoughts from someone who uses Windows and who'd need to change code for this change:

1) I don't know if waiting to 3.5 is needed.  I can make the change to look in the bin directory fairly quickly.

2) Is it safe to add scripts to the PATH?  I'd worry about something in there that's named so it clashes with a standard program such as notepad or chkdsk or more likely something else from another 3rd party program that is installed.

3) A python3.3.exe command should be added so that if someone installs both 3.3 and an eventual 3.4, he or she can run both.

4) The uninstaller should remove the PATH entry if at all possible.

Another alternative is to provide a Start menu item for a "Python 3.4 Command Prompt" that would set up the environment that's similar to the Visual Studio 2008 Command Prompt.
msg156460 - (view) Author: Brian Curtin (brian.curtin) * (Python committer) Date: 2012-03-20 20:42
On 2 and 4, see #3561 for that discussion. A short answer would be that we're consenting adults. Additionally, the current Path-adding installer handles uninstallation.
msg156462 - (view) Author: John Ehresman (jpe) * Date: 2012-03-20 20:52
Does this mean that the PATH entry won't be removed on uninstall?  I can't tell from reading #3561, though I may have missed something.  My worries are about the developer who doesn't know what the PATH is and would find it difficult to diagnose any problems caused by the new entries on the path -- problems that may affect things other than python.
msg156463 - (view) Author: Brian Curtin (brian.curtin) * (Python committer) Date: 2012-03-20 20:54
> Additionally, the current Path-adding installer handles uninstallation.
msg212420 - (view) Author: Martin Dengler (mdengler) * Date: 2014-02-28 11:22
Is this state "closed" per or "languishing"  per ?

I would add a belated "me too" to the "2. Change 'Scripts' to 'bin'" part for consistency, but it seems that the decision has been that the consistency benefits don't outweigh the breakage.

I would have thought that a directory junction (mklink /j Scripts bin) would have obviated the installer breakage concern in , especially given that wheels, which would not be subject to this concern, are coming along nicely.

Is there any appetite to revisit this decision?
msg212423 - (view) Author: Mark Hammond (mhammond) * (Python committer) Date: 2014-02-28 12:25
I get the impression the first link just punted and the second supports the fact many people would see it as an improvement.

So a patch that both works and addresses the concerns would probably be most welcome!
msg212751 - (view) Author: Martin Dengler (mdengler) * Date: 2014-03-04 23:26
Ok, you're right about my link #2; I meant to include this link (a reply to the link I actually included): which I think the pertinent quote is:

"For direct execution, the proposal trades cross-version
inconsistencies for cross-platform consistency. When we *already have*
a consistent cross-platform mechanism in -m, the inevitable disruption
involved in changing the Windows layout seems very hard to justify."

I'll try to whip up a patch for  sub-proposal #2:

   2. Change 'Scripts' to 'bin'

...that uses a directory junction to mitigate the inconsistency concern (windows local admin rights / SeCreateSymbolicLinkPrivilege should not be an issue as mklink /j does not require either), unless someone beats me to it.
Date User Action Args
2022-04-11 14:57:28adminsetgithub: 58510
2015-01-03 14:36:43BreamoreBoysetnosy: + zach.ware, steve.dower

versions: + Python 3.5, - Python 3.4
2014-03-04 23:26:55mdenglersetmessages: + msg212751
2014-02-28 12:25:38mhammondsetmessages: + msg212423
2014-02-28 11:22:27mdenglersetmessages: + msg212420
2014-02-27 14:10:18mdenglersetnosy: + mdengler
2013-03-13 21:19:53ezio.melottisetstage: needs patch
2013-01-28 11:36:24ezio.melottisetnosy: + ezio.melotti
2012-11-03 16:25:09eric.araujosettitle: Move python.exe to bin/ -> Rename Scripts directory to bin and move python.exe to bin
stage: needs patch -> (no value)
versions: + Python 3.4, - Python 3.3
2012-07-30 15:07:38ishimotosetnosy: + ishimoto
2012-03-20 20:54:11brian.curtinsetmessages: + msg156463
2012-03-20 20:52:56jpesetmessages: + msg156462
2012-03-20 20:42:17brian.curtinsetmessages: + msg156460
2012-03-20 20:33:47jpesetnosy: + jpe
messages: + msg156457
2012-03-20 17:17:46v+pythonsetnosy: + v+python
messages: + msg156437
2012-03-20 15:57:58loewissetmessages: + msg156425
2012-03-20 14:24:37VanLsetnosy: + VanL
messages: + msg156410
2012-03-20 11:20:39giampaolo.rodolasetnosy: + giampaolo.rodola
2012-03-19 03:20:51loewissetmessages: + msg156309
2012-03-17 10:03:23loewissetmessages: + msg156149
2012-03-17 01:12:44brian.curtinsetmessages: + msg156118
2012-03-17 01:06:40mhammondsetmessages: + msg156117
2012-03-17 00:55:33brian.curtinsetmessages: + msg156115
2012-03-17 00:48:30mhammondsetmessages: + msg156113
2012-03-16 23:22:22brian.curtinsetmessages: + msg156102
2012-03-16 23:06:01eric.araujosetnosy: + loewis, tim.golden, eric.araujo, mhammond
messages: + msg156097
2012-03-14 16:29:34brian.curtincreate