The py Python launcher is a great improvement over a few years ago when managing multiple Python installation was tedious.

However, it does not solve one annoying problem: the Scripts directory. If you install tools like mypy, pyqt-tools or pyinstaller, to be able to use them, you need to have the Scripts directory in your PATH variable. And if you have multiple Python installations, you are back to square 1 where you have to explicitely modify your PATH according to the version of Python where the tools have been installed.

To give a practical example, at work, I have Python 3.1 because some of our software are distributed as .pyc for this version of Python, Python 3.5 for the same reason and Python 3.7 for all the developments which do not incur the previous dependencies.

The default environement with Python and Python\Scripts added to the path is Python 3.5 . However, for all PyQt developments, I use Python 3.7 . I launch my program with py -3.7 myfancygui.py  but when I want to access some of the pyqt tools like pyuic5, I need to explicitely add Python3.7\Scripts to my PATH.

The technical solution is not clear to me, but it would be nice to duplicate the benefits of the py launcher to the Scripts directory.

Some random propositions:

1. Create a pyscript launcher, which would work like py but would take as command-line the name of the script to run:

    pyscript -3.7 pyuic5

2. Let py execute a command-line with proper environment for that specific version of python:

   > py -env-3.7
   Environment adjusted for Python 3.7
   > pyuic5 ... works fine
   > exit
   Back to default environement

There are probably other stratagic ways to reach the same result.

Most items in the Scripts directory can be run using the `-m` flag to Python, so you can use something like `py -m pip` to run pip without needing the Scripts directory in PATH.

If an individual project like PyQt doesn't support -m, it's relatively easy for them to add, so it might be worth suggesting to them.

Thanks for the quick feedback.

I agree that it makes sense for python modules to support -m. However, PyQt comes with many executables originally written in C++ for Qt (designer, assistant). It feels a bit strange to add a module with that name, just for the purpose of creating a -m target so that you can run it without Scripts in path.

Moreover, some of these C++ exectuables depends on DLL which are only in the Scripts directory and it might not work. I do not think that your proposal addresses the full problem.

> Moreover, some of these C++ exectuables depends on DLL which are only in the Scripts directory and it might not work.

In this case, perhaps these tools should be in a separate directory? A simple .py script could be added to Scripts that works with "-m" and launches the executable.

> I do not think that your proposal addresses the full problem.

You'll have to excuse us. We've had a lot of experience in this area with this problem, and so we'll be very quick to rule out imaginary proposals like the one you posted that we know are technically infeasible.

> Create a pyscript launcher, which would work like py but would take as command-line the name of the script to run ...

This is spelled "py [-x.y] -m [script]", but it's up to the libraries to support it. We can't force them to do it.

> Let py execute a command-line with proper environment for that specific version of python

"Proper environment" is a matter of opinion, as evidenced by hundreds of issues that arise every time people try to get clever here.

And %PATH% on Windows is a system setting that has an impact on every application that launches, and also has different behaviour on different version of the OS (because it's a system setting, so the system can change how it uses that setting over time).

Perhaps what you want is a virtual environment? Then your activate command is spelled "activate" and your exit command is spelled "deactivate". These have some of the issues I hinted at, as well as many of their own, but at least they already exist and are in widespread use, so most libraries are going to avoid relying on things that don't work. Inventing a new approach here would create and entirely new set of things that don't work, and it'll take the ecosystem years to catch up (and many won't even care to try until there's critical mass usage of the new approach, which won't happen until the ecosystem catches up, etc. etc.)

Ok, I'll close my request if you do not think of any value in it. 

Py is such an elegant solution, I wish something as simple would also address this problem.

Virtual environement do have the downside of not coming directly with Python. In my work environment, extra Python packages are strongly discouraged and my colleagues are not proficient enough in the Python ecosystem to use venv.