Upload .nupkg file or .zip equivalent to python.org

[solvingj]

Feature or enhancement

Please add another package/publish step to upload the .nupkg files to python.org alongside the other precompiled package options.

Alternatively, and preferably....

Just zip up the tools subdirectory of the nuget package separately and upload that to python.org named as "portable install".

Pitch

The current build automation is just a few inches shy of addressing a much broader and more general case of CI. With one of the "relatively trivial" modifications suggested, the Python could simplify any primitive CI flows which don't use nuget package management.

In either recommended case, nothing has to be re-built, no additional tests are needed, because it's the exact same functionality as the nupkg. Just add a second capture/upload step during the stages which builds the nupkg, just with a different name and destination. The hardest part is the organizational stuff: updating the website and docs to describe this new thing, etc.

But Why?
The .nupkg package is a very awesome and practical acknowledgement of the world of CI use-cases. Thanks for this. However, it's coupled to the concept/stack of nuget package management, and many CI teams in enterprise organizations can't or haven't adopted that strategy.

Primitive CI flows (as found in many enterprise organizations) want all of their pre-compiled binary tools to follow the simple template:

• curl to download
• zip or tar to extract
• run...

Currently, we can "hack" the .nupkg package to get close to this, but with a bunch of unnecessary nuance:

1. It's a .nupkg, so we have to rename it to .zip to unzip it with either Powershell or bsdtar
2. The files we want are in a tools subdirectory
3. It's hosted on nuget.org which has drawbacks:
   • Security folks don't like it, it's less official and more "scary" than python.org
   • Scripts have to deal with different URLs, naming conventions, she verification, etc, compared to python.org

[arhadthedev]

@Yhg1s (as a release manager)

[Yhg1s]

More of a question for @zooba at this point.

[zooba]

I'm concerned about users picking the zip file and being surprised that they don't have proper update and uninstall functionality, or that their IDE or py.exe can't find it (yes, this has happened in the past). It won't be on PATH, and it won't have working pip.exe in it (python -m pip is fine though). And if we do update all the docs to point out the zip file, we're somewhat obliged to make sure it meets people's expectations, even if those expectations are impossible to meet. I'd rather not pile up more obligations like that, especially since the majority of this tech support seems to be carried by the webmasters (who are not a support group, to be clear!).

Frankly, teams that are concerned about the trustworthiness of nuget.org ought to be way more concerned about downloading from arbitrary web sites. Nuget at least scans and detonates every upload, so anything malicious doesn't last long, and the packages are signed and verified.

It's easy to construct a direct download link from nuget (it's https://www.nuget.org/api/v2/package/<PACKAGE>/<VERSION>, e.g. https://www.nuget.org/api/v2/package/python/3.11.2), or you can go to the package page and copy the URL from the "download" link. You don't get any signature verification in this case, but it was checked on upload, and Nuget's servers are at least as trustworthy as Python's. Perhaps this is worth mentioning in the docs, to save people figuring it out themselves?

So overall, I'm not opposed to putting up a zipped copy on python.org if it's that big a deal. But I am opposed to making it seem like a sensible choice for the ~tens of millions of downloads we get each month. The vast vast majority of those users will get burned much quicker than usual if they do a manual install, and nobody likes it when we point out that they simply made the wrong choice ("why would you offer it if it's wrong?" is a real question I get asked enough already...).