[Python-Dev] PEP 370 - per-user scripts directory on Windows

Steve Dower Steve.Dower at microsoft.com
Fri Feb 13 15:27:31 CET 2015


Launching non-Python scripts from py.exe is not going to work as well as you may hope. There will be numerous subtle bugs due to the cmd->py.exe->cmd wrapping (Powershell users would have seen this with some console apps or batch files). I think having a global command to add a particular Python to PATH for the current session will work best here, and yes, I'm working on it.

If py.exe starts defaulting to whatever is on PATH then I don't see the point of it. Knowing that you'll get the latest 2.x version by default is quite handy (I'd be quite okay changing that to 3.x, though it is specified in the original PEP). For me, the point of py.exe is to be able to ignore PATH completely.

Adding more commands to the launcher args (eg. -ipy) will make the parsing far more complex, especially when deciding which args to consume and which to forward. I think you can make a copy of the launcher called ipy.exe and add ipy.ini with the path to IronPython in it as default.

Cheers,
Steve

Top-posted from my Windows Phone
________________________________
From: Paul Moore<mailto:p.f.moore at gmail.com>
Sent: ‎2/‎13/‎2015 3:20
To: Glenn Linderman<mailto:v+python at g.nevcal.com>
Cc: Python Dev<mailto:python-dev at python.org>
Subject: Re: [Python-Dev] PEP 370 - per-user scripts directory on Windows

On 13 February 2015 at 10:15, Glenn Linderman <v+python at g.nevcal.com> wrote:
> Maybe restricting it to running ".py" files or ".exe" files would be
> reasonable. That covers entry points (which should be the norm for
> newer projects) and Python scripts (which are the most likely things
> to be portable).
>
> The WINDOWS py launcher hardly needs to be portable.  Batch/CMD files also
> seem useful on WINDOWS. And Powershell?
>
> If a launcher is developed for or enhanced for other systems, shell scripts
> may be useful, and Batch/CMD not.

By "portable" in this sense I meant "not written by a Unix developer
who hadn't thought about Windows much". I was comparing Python files
with a .py extension and extensionless Python files, specifically (my
wording didn't make that clear, sorry). Yes, files with extensions of
.bat or .cmd or .ps1 are probably written for Windows only. But I
think it's getting out of scope of the launcher to decide to use
cmd.exe to launch .bat and .cmd files, and powershell to launch .ps1
files.

Regardless, my real point was that there can be all sorts of stuff in
the Scripts directory, and I'm not convinced that this is a direction
the launcher should be going in. Someone *could* make a case for
launching certain types of file that might be in there, but I'm not
going to be that person.

One thought - it's not hard using pkg_resources to enumerate all
available console_script entry points, pick one and run it. So you
could pretty simply write a script (that itself could be run with the
launcher) to run anything in Scripts that's built via entry points
(which is the recommended way these days).

# launch.py
import sys
import pkg_resources

# Get the script name
script = sys.argv[1]
# Remove our name from sys.argv
del sys.argv[0]

# There's probably a better API you can use
for ep in pkg_resources.working_set.iter_entry_points('console_scripts'):
    if ep.name == script:
        fn = ep.load()
        sys.exit(fn())

# Couldn't find the entry point
print("No entry point called {} available".format(script), file=sys.stderr)
sys.exit(1)

Now you can do "py launch.py pip --help" and it will run pip for you.

If a project isn't exposing its scripts as entry points, ask them to :-)

Paul

Paul
_______________________________________________
Python-Dev mailing list
Python-Dev at python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: https://mail.python.org/mailman/options/python-dev/steve.dower%40microsoft.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150213/67bb8d16/attachment-0001.html>


More information about the Python-Dev mailing list