OS: Windows 7 Ultimate x64
Python version: 2.7.3 x64

win_add2path.py in the scripts directory is supposed to add the Scripts directory according to its source.  However, it tries to add $PYTHONPATH/Scripts, when in fact the Scripts directory is at $PYTHONPATH/Tools/Scripts in 2.7.

However, it seems like e.g. Setuptools still installs itself in $PYTHONPATH/Scripts, so maybe the right solution is to add both directories.

Furthermore, the script sets the default user path to %PATH%, which is not correct at least on windows 7.  I have to manually delete this part of the user path to get the user path merged correctly with the system path in cmd.exe.

[this response appears to have got lost in an email black hole somewhere]

I assume that "$PYTHONPATH" is actually referring to sys.exec_prefix
(and not the PYTHONPATH env var which has nothing to do with this).

In any case c:\python27\scripts is still the place for scripts. There is
a c:\python27\tools\scripts (which you're welcome to add to your %PATH%
if you find the scripts useful) but that's not the place where
user-installed packages are expected to install their executable helper
scripts.

Without looking closely, I think I agree about default the user path to
%PATH%. I'll add Christian Heimes to this call who, I think, wrote the
original code.

Ok, thanks for clearing that up.  And yes, I meant the pythonpath variable in the script, which seems to be derived from sys.executable.

But in that case, it's unfortunate that the c:\python27\scripts dir is not created during install.  I did win_add2path right after install, and then it didn't add the scripts path because it didn't exist.

Should we create the scripts dir during install?  Is it that big a deal?

Presumably we can look at this after the discussions about the installer scheduled for PyCon 2015?

It looks like the script hasn't been updated for the moved user scripts directory (under %APPDATA%), but otherwise this is not a bug and can be closed.

Pip and/or setuptools will add the Scripts directory when needed, so it's not a big deal that the installer doesn't create it. In 2.7.9 and later, and 3.4 onwards, the Scripts directory is created as part of the ensurepip step of the install, so it's pretty much a moot point anyway.

This script adds them to PATH. As I said, the original issue is not a bug, but it has drawn attention to something we apparently missed a while ago.

Steve - is it the fact that it's not using the versioned user-site directory that you're referring to?

... because I think it does do that (see http://bugs.python.org/file38085/userscripts.patch which updates this file)

I think the problem here is that as the OP mentioned, win_add2path.py doesn't add the directory if it doesn't exist, so if you run it immediately after install, it won't add the directories that don't exist yet. And because it's setting the registry entries to make the path changes persistent, you only run it once and don't rerun it after those directories are created. Although if you did, that would fix the problem...

Maybe win_add2path.py should add the directories even if they don't exist? It only means removing the isdir check from the line

    if path and path not in envpath and os.path.isdir(path):

I don't really have a feel for whether that would be a good idea. I guess the only harm would be a bit of clutter on %PATH%, and probably no-one cares about that...

One further thought - the installer can't create the user scripts directory if you're doing an all-users install, that's sort of the point of "all users". It could do so for a per-user install, but then there would be an inconsistency that I don't think is a good idea.

So maybe skipping the "does the directory exist" check is the only option.

Here is a patch to fix the issue.

Ah, you're right, it was fixed. Guess I misread my local copy (or I was looking at 3.4).

That patch looks good to me. It'll help cover the case where someone does something to create the directory.

Cool. I'll try to set up a test (it's not covered by the testsuite AFAICT) on a VM or something, just to confirm I haven't broken anything.

One further thought. This is a change in behaviour (albeit to a script in Tools), so I'm inclined to say it's a new feature for 3.5, rather than a bugfix to be backported to 2.7 and 3.4.

For users of 2.7/3.4, the workaround is simply to rerun the script - it doesn't add directories it has already added, so it's safe to rerun to add newly created directories.

There's actually a bug in the pre-3.5 script beyond the "does the directory exist" check. The code is

    if hasattr(site, "USER_SITE"):
        userpath = site.USER_SITE.replace(appdata, "%APPDATA%")
        userscripts = os.path.join(userpath, "Scripts")

which sets userscripts as %APPDATA%\Python\Python34\site-packages\Scripts, which is completely wrong. Stripping off 2 directory levels gives the correct answer, but that seems a bit arbitrary - using sysconfig seems more robust.

Also, there's another point made in the original report - the registry variable HKCU\Environment\PATH is set to "%PATH%;<the stuff we add>". That's just wrong - the user PATH variable is added to the system PATH variable, so why interpolate the existing value? It may be that the behaviour varies in different Windows versions, I don't know enough about how older versions work to comment on that.

There are enough bugs here that I suspect that very few people have ever used the script :-( Maybe it would be better to leave the older versions alone, and simply rewrite or remove it for 3.5 (I know Steve has ideas about providing new path-setting scripts)

Any interest in making a PR for this patch?

I've refreshed the version as neither the patch was applied nor was the bug mentioned in msg239074 fixed so far.