Please provide a .zip Windows release of Python that is not crippled/for embedding only

[et]

BPO	36010
Nosy	@pfmoore, @ncoghlan, @tjguk, @jkloth, @zware, @eryksun, @zooba, @christian-korneck
PRs	bpo-36010: Add venv to the nuget distribution #12367 [3.7] bpo-36010: Add venv to the nuget distribution (GH-12367) #12634

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2019-03-30.21:50:25.141>
created_at = <Date 2019-02-16.14:20:20.166>
labels = ['easy', '3.8', '3.7', 'expert-installation', 'OS-windows']
title = 'Please provide a .zip Windows release of Python that is not crippled/for embedding only'
updated_at = <Date 2019-03-30.22:03:33.908>
user = 'https://bugs.python.org/et'

bugs.python.org fields:

activity = <Date 2019-03-30.22:03:33.908>
actor = 'et'
assignee = 'none'
closed = True
closed_date = <Date 2019-03-30.21:50:25.141>
closer = 'steve.dower'
components = ['Installation', 'Windows']
creation = <Date 2019-02-16.14:20:20.166>
creator = 'et'
dependencies = []
files = []
hgrepos = []
issue_num = 36010
keywords = ['patch', 'easy']
message_count = 41.0
messages = ['335687', '335690', '335691', '335693', '335698', '335701', '335702', '335703', '335707', '335725', '335727', '335728', '335742', '335743', '335744', '335773', '335775', '335779', '335781', '335786', '335846', '335849', '335871', '337948', '337949', '337952', '337956', '337977', '337978', '337979', '337985', '337992', '337998', '338080', '338242', '338246', '338262', '338279', '339212', '339223', '339224']
nosy_count = 10.0
nosy_names = ['paul.moore', 'ncoghlan', 'tim.golden', 'jkloth', 'jeremy.kloth', 'zach.ware', 'eryksun', 'steve.dower', 'et', 'chris-k']
pr_nums = ['12367', '12634']
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue36010'
versions = ['Python 3.7', 'Python 3.8']

[et]

It would be really useful if you could provide a .zip Windows release of Python that is not crippled/for embedding only.

The reason is simply is that right now, I am having constant pain & trouble with it writing an automated build script for Windows (.bat) that works on a Python-free machine.

Specifically the installer has:

1.) no usable functionality in an automated build environment (%PATH% is very unnecessary or even undesirable to set up for a Python install only temporarily downloaded for a build)

2.) possibly conflicts with existing installs (making an automated build break/affect other Python installs/leaving other side effects, which is extremely undesirable and ugly)

3.) can break into a completely unusable state when interrupted (where the install doesn't complete, but running it again also doesn't, needing complicated special logic to nuke it)

NONE of these would be an issue if there was just a .zip. And there is, of course, in form of the embedded install - but that one is useless to me for an automated build because I need pip, and it doesn't support running pip.

[jkloth]

For a "tool-style" installation of Python, see the 'PCBuild\find_python.bat' script in the Python source tree, specifically the nuget section.

Ultimately, it is just:

nuget install pythonx86 -ExcludeVersion -OutputDirectory "some\path"

which will create an installation of the latest python at "some\path\pythonx86".

[et]

Is nuget a standard windows utility? What happens if that process is interrupted? What happens if I install it twice to different folders? What happens if I want a specific python version?

Don't get me wrong maybe it can do all these things, but why on earth do I need this? I can even produce this .zip myself, just the regular installer run with /Q and then copy it, but I need to do that for each new release and everyone else who might need it will also need to do that.

Is it really that much work to do this centrally once so it's available for everyone? After all the embeddable install is already available in such a way, it's just that being the stripped down embeddable version its use is limited

[jeremykloth]

On Sat, Feb 16, 2019 at 8:32 AM jt <report@bugs.python.org> wrote:

Is nuget a standard windows utility?

No, but if your script can download a zip of Python, it could download
the nuget executable.

What happens if that process is interrupted?

Same as interrupting an unzip operation.

What happens if I install it twice to different folders?

NuGet installs are basically just an unzip process, so you simply have
2 different folders containing a Python installation.

What happens if I want a specific python version?

Use '-Version <version-string>' as an option to 'nuget install'.
<version-string> can be any of the versions listed on
https://www.nuget.org/packages/python/.

Don't get me wrong maybe it can do all these things, but why on earth do I need this? I can even produce this .zip myself, just the regular installer run with /Q and then copy it, but I need to do that for each new release and everyone else who might need it will also need to do that.

Is it really that much work to do this centrally once so it's available for everyone? After all the embeddable install is already available in such a way, it's just that being the stripped down embeddable version its use is limited

It is available to all and is provided by the Windows release manager,
see https://www.nuget.org/packages/python/.

[et]

So is that a no for a regular .zip release here? https://www.python.org/downloads/windows/

Don't get me wrong I'm all for options, I just don't get why there is no simple tool-less binary archive for Windows. Why are the only options different variants of installers or additional tools? Why do I need to fetch another tool just to fetch Python?

If this is the final decision then I recommend at least mentioning NuGet prominently on here: https://www.python.org/downloads/windows/ (as an alternative to the so-so regular windows installer, since while that one works well enough for a manual install, for an automated one it's just not that ideal)

[jeremykloth]

Why do I need to fetch another tool just to fetch Python?

Well, you still need a tool to fetch the zip and you need another tool
to unzip it. If not, how are you bootstrapping your script for those
uses?

If this is the final decision then I recommend at least mentioning NuGet prominently on here: https://www.python.org/downloads/windows/

As far as final say goes, I have no control, but it does seem somewhat
reasonable.

(as an alternative to the so-so regular windows installer, since while that one works well enough for a manual install, for an automated one it's just not that ideal)

So are you just looking for an automated regular installer where the
end result shows up in the Installed Apps list, or a scriptable
build-tool package?

[et]

Well, you still need a tool to fetch the zip and you need another tool to unzip it

Windows 10 actually has everything necessary around, so I don't! That's kind of the beauty of it, the other point being that every dev knows how to deal with a .zip (more than know NuGet, i would assume)

So are you just looking for an automated regular installer where the
end result shows up in the Installed Apps list, or a scriptable
build-tool package?

Actually I would explicitly NOT want it to show up in Installed Apps, or any other sort of advanced script. Sorry if I haven't been clear on that, I want to avoid any such side effects as much as possible.

What I want is the TARGET FOLDER result of running the regular windows installer. If you haven't noticed, this folder can be copied onto a system where it was never "installed" and with a simple .bat script (or powershell, ...) that sets %PATH% and %PYTHONPATH% you can use it in-place with no further install required.

That's why I'm asking for this, there doesn't seem to be even any need to install Python, and since for an automated build I want to minimize side effects, why would I want anything more than a .zip in that case? I can only see downsides

[zooba]

So is that a no for a regular .zip release here? https://www.python.org/downloads/windows/

Correct, it's a no.

The main reason is because people use it wrong and get into trouble, and we don't want to support that. (More after the docs link below)

If this is the final decision then I recommend at least mentioning NuGet prominently on here: https://www.python.org/downloads/windows/

Agreed. It's already documented at https://docs.python.org/3/using/windows.html and perhaps that's the better page to feature prominently on the download page?

Basically, the breakdown of packages we want to provide are:

• easy for "light interactive use" (Windows Store)
• full developer kit (regular installer)
• app-local redistributable (embeddable package)
• zero-impact CI install (nuget package)
• "install" from source (PC/layout script)

(Note the last is currently undocumented outside of the script itself, but I'm planning to write something soon.)

Adding more than this to our support burden is not desirable until we have more [highly responsive] volunteers (not even core committers, we're just at a point where technical support staff would be helpful).

[et]

Okay, I just tested switching to the NuGet package and appear to have hit some sort of issue:

C:\myproject\tools\windows\.python-win\python\tools\python.exe: No module named venv
Traceback (most recent call last):
  File "C:\myproject\tools\windows\\windows-build.py", line 129, in <module>
    do_build()
  File "C:\myproject\tools\windows\\windows-build.py", line 60, in do_build
    ".python-win", "spen-venv")
  File "C:\myproject\tools\windows\.python-win\python\tools\Lib\subprocess.py", line 395, in check_output
    **kwargs).stdout
  File "C:\myproject\tools\windows\.python-win\python\tools\Lib\subprocess.py", line 487, in run
    output=stdout, stderr=stderr)
subprocess.CalledProcessError: Command '['C:\\myproject\\tools\\windows\\.python-win\\python\\tools\\python.exe', '-m', 'venv', 'C:\\myproject\\tools\\windows\\.python-win\\spen-venv']' returned non-zero exit status 1.

Is this expected with the NuGet variant? Can I somehow install 'venv' on top? I didn't have this issue with the install obtained by running the Windows Installer with /Q

[zooba]

The whole point of a venv is to give you a separate directory with a "stand alone" Python. As that's what you just installed with nuget, there's no point in creating a venv - just pip install directly into it.

Alternatively, you can pip install virtualenv and use that.

[pfmoore]

The whole point of a venv is to give you a separate directory with a "stand alone" Python. As that's what you just installed with nuget, there's no point in creating a venv

However, shipping a copy of Python with a non-optional element of the stdlib omitted seems at a minimum user-unfriendly, and possibly even outright broken. (We've had similar discussions in the past over Linux distros splitting parts of the stdlib into optional "devel" packages).

Is there a technical reason why the venv module cannot work with the nuget package? If not, then I'd suggest that we simply include it, and don't pre-judge what people might want to do with it. If there *is* a technical problem, let's document the limitation, and note in the venv docs that it may not be present in all installations.

(I'm specifically interested in venv here because there's a possibility that at some point, virtualenv will change to use the core venv functionality under the hood on Python 3+, and if that happens, your suggestion to use virtualenv would no longer work).

[zooba]

There certainly used to be a problem where venv was totally reliant on Python being in the registry to work properly. I'm not sure if that's still the case - possibly with the new redirector in 3.7.2+ it's fixed.