Patch attaced.

Hi, and thanks for your interest in improving distutils2.

I am not a Windows user, much less developer, so I have many questions about your proposed pysetup.bat:
- Will “@%~dp0\..\python.exe” get the proper path for people who do not install Python to C:\?
- Aren’t there issues with .bat scripts (or maybe it’s with .com scripts, I never remember)?
- Shouldn’t we install a pysetup.py script instead?
- Shouldn’t we generate an .exe file instead (see #12394)?

In other words, I need more info from Windows experts about what works best for Python developers :)

> - Will “@%~dp0\..\python.exe” get the proper path for people who do not install Python to C:\?

%~dp0\..\python.exe locates python relative to the batch file (one
directory up) so will work as long as the bat file is in Scripts. The
@ just suppresses echo of the command.

> - Aren’t there issues with .bat scripts (or maybe it’s with .com scripts, I never remember)?

Yes. They don't nest, so to invoke pysetup in a batch file, you need
to write "call pysetup.bat". If you just use "pysetup", the command
never returns causing silent failures. Personally, I hate bat files
for this reason alone, but others seem happy to put up with them.

> - Shouldn’t we install a pysetup.py script instead?

That would be better, in my view.

> - Shouldn’t we generate an .exe file instead (see #12394)?

exe files probably give the best user experience, but are opaque which
is mildly annoying. Also, test very carefully on Win7. I have a vague
recollection that exes with setup and/or install in the names invoke
UAC, which is a complete pain. easy_install suffers from this, I
believe.

> In other words, I need more info from Windows experts about what works best for Python developers :)

Personally, "python -m packaging.run" works fine for me. I'd prefer
not to have a pysetup command at all, and change the documentation to
refer to the python -m form throughout. Second best would be an exe,
third would be pysetup.py (but again, the docs need changing), and
finally a bat file.

Another option would be a runnable pysetup module, so that python -m
pysetup (or maybe an install.py so python -m install) would work.
Paul.

Also, we normally set ".py", and ".pyw" into the PATHEXT environment variable, so that a script "pysetup.py" can be invoked from the command-line as just "pysetup" without the suffix. This gives the same experience as using a "pysetup.bat".

I would say that pysetup seems a little more polished (and shorter) than the -m form, especially for users new to packaging. After that, I agree with Paul's ordering of .exe, with the setup script having to be named pysetup-script.py if we use the "standard" mechanism, or else if we use a custom .exe, it can of course be called whatever we want.

[Paul]
> %~dp0\..\python.exe locates python relative to the batch file (one directory up) so will work as long
> as the bat file is in Scripts. The @ just suppresses echo of the command.

Okay, so a pysetup.bat script installed by pythonX.Y.exe will be put in that Python’s Scripts directory and will call that Python when invoked.  Sounds good.

>> - Aren’t there issues with .bat scripts (or maybe it’s with .com scripts, I never remember)?
> Yes. They don't nest, so to invoke pysetup in a batch file, you need to write "call pysetup.bat". If
> you just use "pysetup", the command never returns causing silent failures. Personally, I hate bat files
> for this reason alone, but others seem happy to put up with them.

Noted.  (I’ve been reading old mailing list archives and found this sort of criticism in bat vs. com discussions.)

>> - Shouldn’t we install a pysetup.py script instead?
> That would be better, in my view.

Okay, I can do this for the short term.  勇刚.罗 (sorry if that does not read right, I seem to have font problems), would that satisfy you?

>> - Shouldn’t we generate an .exe file instead (see #12394)?
> exe files probably give the best user experience, but are opaque which is mildly annoying. Also, test
> very carefully on Win7. I have a vague recollection that exes with setup and/or install in the names
> invoke UAC, which is a complete pain. easy_install suffers from this, I believe.

Oh dear, what an horror story.  I really wish we won’t have to rename pysetup, it’s the only generic and available name we could agree on.

> Personally, "python -m packaging.run" works fine for me. I'd prefer not to have a pysetup command at
> all, and change the documentation to refer to the python -m form throughout. Second best would be an exe,
> third would be pysetup.py (but again, the docs need changing), and finally a bat file.

Thanks for the feedback.  I don’t think we’re going to move away from a main script; we’re making packaging more useful and more robust, and having a script is IMO a message as well as a convenience.


[Vinay]
> After that, I agree with Paul's ordering of .exe, with the setup script having to be named
> pysetup-script.py if we use the "standard" mechanism, or else if we use a custom .exe, it can of course
> be called whatever we want.

I don’t understand the notions of standard vs. custom.  Does standard mean setuptools?  #12394 is not quite ready yet, so nothing is set in stone, but if possible I’d prefer to generate pysetup.exe.  Let’s move the sub-discussion there.

I'd rather we not add a batch file and choose one of the other options outlined above. I haven't used this new pysetup thing so I'm not familiar with which would be the best experience, but in other cases all of the ones listed are better than batch files.

> I don’t understand the notions of standard vs. custom.
> Does standard mean setuptools?  #12394 is not quite ready yet, so
> nothing is set in stone, but if possible I’d prefer to generate
> pysetup.exe.  Let’s move the sub-discussion there.

Okay, we'll continue on #12394, but I'll comment here on "standard vs. custom" - by "standard", I meant the setuptools way of doing it, but not necessarily using the setuptools code - see my comment in #12394 on an alternative. The basic method is that used by setuptools, but the specific implementation is different - somescript.exe opens somescript-script.py, reads a shebang line to find which Python to invoke, then invokes it with the script. By "custom" I meant "something else" without anything specific in mind - and I'm not sure it's worth the bother and extra work of a customised pysetup.exe.

Perhaps all or at least some of this could be simplified in 3.3 if the PEP 397 launcher is included in Python. Mark Hammond has re-started discussions about this on Python-dev, and hopefully we'll have a consensus to get it in.

distutils2 is dead, closing.