Yeah, that’s what I’m considering. I’m thinking possibly a portable version of PyManager that basically only supports py install --target (it would, of course, be an identical codebase. It just wouldn’t let you get into configurations that we don’t want to remotely diagnose when they break, which will be almost immediately for most people, I would expect)
2 Likes
Just putting the test build through some testing (tomorrow), so should be ready soon.
Have a screenshot in the meantime:
3 Likes
Perhaps I’m thinking of just usual MSIs then.
I’d like it to double check with me first, but I’m far from angry about a WIP example. It’s simple, and as far as I could tell, correctly did exactly what it claimed to do.
I should have phrased that as “will stop working going forward, using their current install method relying on NuGet packages”.
Still, the point remains: What you are suggesting as part of the PEP is to “deprecate and phase out the traditional installer and Nuget packages”.
I don’t really see how that relates to the PEP’s main concern, which is to make the Windows Python installation experience a better one for the novice or casual user and where we currently point users to either an exe installer or the Windows Store (indirectly via the python.exe shim in Windows).
IMO, phasing out other distribution formats is an orthogonal topic and should not handled by this PEP, esp. since the installation story using one of those alternative mechanisms based on the NuGet packages already is a pretty decent one. It’s better to focus on the user experience with the new “Python Installation Manager”.
2 Likes
Okay, we’ll keep the NuGet packages.
3 Likes
Thanks, Steve 
Is it planned a support for interpreter offline installs?
Yes, search the PEP for “offline”.
2 Likes
Removing the Store packages would reduce the number of options users face when choosing a Python runtime.
This is written in rejected segment, but at the same time this pep also mentions that the goal is to stop publishing all other installers. This seems to contradict.
I also would like to suggest a short statement about „conflict of interests“, especially as this would push users into a Microsoft controlled closed marketplace that is fairly controversial. The requirement for that is from my reading of PEP 1 maybe there, but it is ambiguos and cant remember a pep to look up that is compareable to see if it had that part. A clarification would just be the correct thing to do. Even if there is no real conflict of interest, from connection to an employer, which I assume, stating that and why would help. If I have just missed it in the PEP text then I am sorry and please ignore this paragraph.
This doesn’t push users into anything Microsoft controlled, unless you mean the MSIX file format - which is little more than a zip file. The PEP explicitly states that the MSIX file will be available from python.org, without requiring users to get it from the Microsoft store.
And in any case, how is this different from Linux, where you get Python from your distribution package manager (or you build it yourself from source)?
2 Likes
I don’t generally use Windows, and trust @steve.dower and others to make the experience on Windows great. I just wanted to mention that I do use choco (Chocolatey) in the CI for my various libraries. I’d like for this use case to continue to work, but I don’t really care too much about the mechanism. E.g. if there’s something better or different I could be doing, I’m happy to switch. This approach has Just Worked for me for a long while.
It’s not ideal though, mostly because a) AFAICT I can’t just use a Windows docker image like I can on Linux, unless that’s changed; b) Installing all the active Pythons is slooow. That step is by far the slowest part of my CI runs.
1 Like
FWIW I found setting up a free-threaded Python using nuget pretty straightfoward once I figured out the necessary Powershell invocations.
See this PR which updates https://py-free-threading.github.io to tell people to install the nuget distribution: Add nuget windows install instructions by ngoldbaum · Pull Request #130 · Quansight-Labs/free-threaded-compatibility · GitHub
3 Likes
Okay, new demo build is ready (enough) for people to try it out.
https://cpythonpackages.blob.core.windows.net/pkg/python-manager-0.1a4.msix (~20MB)
Make sure you’re set up properly:
- If
py,pythonorpymanagercommands don’t work, check “Manage App Execution Aliases” - If
pydoesn’t work, you might need to uninstall your existing “Python Launcher” from “Installed Apps” - If
pythonjust launches an existing install, you might need to remove existing installs from PATH (or just ignore this command for testing) - File associations may not update until you first run one, or you can right-click and “Open With” to change your default app
Things to try:
py list --online ">=3.10"py install 3.13tpy list --format=jsonlpython file-with-shebang.py(e.g.#! /usr/bin/python3.8)- internet disabled
- add
-vor-vvto subcommands (or setPYMANAGER_DEBUGfor too much info all the time) - look in
%TEMP%for logs - whatever you are most concerned about!
Or check out the quick video demo:
7 Likes
I also made a start on updating the docs page: pymanager/doc/using.rst at main · zooba/pymanager · GitHub
Docs-wise I think we balance out about even compared to before, possibly a bit simpler due to fewer options (though I still need to figure out a nice way to not ship the test suite to every single user… if anyone wants to convince me we don’t need to ship it at all, that’d be great! But I think we’ll need an install option that includes it for the handful of people who want to verify the install… nobody has ever complained that the current Store app and the NuGet packages never included it)
The demo looks fantastic and IMO will make using Python on Windows, in particular for inexperienced users, significantly easier.
My only real concern about the proposal is this part:
The recommended command for all scenarios is
py. This may be used anywhere in place ofpythonorpymanager, or in place of the olderpy.exelauncher.However, we recommend that documentation show
pythonas the standard command for launching Python. In these contexts, this command as installed by PyManager will work correctly and reliably, just as thepythoncommand behaves inside of virtual environments or on other platforms.With one minor exception, the
pymanagerandpycommands are synonymous.
We usepyby default for brevity, but recommend that scripts that are attempting to install and use PyManager should probably usepymanager, due to the lower chance of encountering a conflict with preexisting installs. The only difference is when running the commands without any arguments:
I feel like promoting the py command as the recommended way to do everything is a mistake. I fully agree that it is necessary to retain it for backwards compatibility, and I think it’s not a terrible idea to add to it the new functionality as outlined, and people are then free to work primarily with py if they want. But just as you recommend that the official advice should be to use python to run an interpreter, even though py would work too, I think that the official advice should be to use pymanager to manage Python interpreters.
Having the official line be “use pymanager to install Python, use python to run it” is clearer conceptually for users – the two have good separation of concerns, they operate at different levels, and the dual roles are analogous to rustup/rustc and juliaup/julia.
The fact that py can do a hybrid of the functionality of the other two commands, but in some situations it would be definitely be better to use the actual python and pymanager, but in no situation is it actually preferable to use py, makes it a bit of a confusing thing to recommend.
My feeling is also that the shorter command implies something more “fundamental”, which is kind of the opposite of how it really is.
I think it also lends itself better to potential future extension of pymanager to other platforms. There’ll be a lot of web pages out there that explicitly say that the py command can only be used on Windows. So better in my view to try to gently shepherd people towards the new command that carries no existing connotations or baggage.
4 Likes
(“PyManager” name open for bikeshedding)
Should renaming to “pyup” be considered?
1 Like
I don’t quite understand this - it’s always preferable to use py when you have it. The only place it’s not preferable is when recommending users run a command that may be run on any platform (e.g. in your docs).
And we need the pymanager command (this could be longer and uglier if you like?) for cases where you don’t have py (because like everything, it’s optional, and it’s too late for us to force preferences on the Python community).
Personally I dislike the “up” style naming, but especially when put against py. It would have to be pythonup, which is still too close to python for my liking.
I also don’t see how “listing and installing the official builds” is the opposite of “fundamental”.
(I guess as an aside, the py command isn’t doing a hybrid of the other commands. There’s only one set of commands, officially implemented in pymanager, and the other aliases have some disabled or changed defaults. But there’s no hybrid going on. If there are ways I can make that clearer, then I will, but I’m quite happy with implying “py and pymanager do everything; python can’t manage”)
1 Like
I agree this is essentially just a matter of how things are presented, but I think that in general, people think of “run” and “manage” as two separate ideas (as evidenced by pairs like rustc/rustup)… So we have python=run, pymanage=manage, and py=… both? So it’s not so much that py is a worse choice, but rather that it confuses that distinction that people see. And if you add to that the fact that the traditional launcher was firmly in the “run” camp, the new py feels like a strange hybrid “run with manage added on”.
Whereas you’re presenting the view that py is for everything, pymanage is for when py is somehow missing, and python is for cross-platform. Which is also valid, but harder to internalise (why would py be missing? why isn’t python standard on Windows?)
In the end, people will come up with their own rationalisations, but it will be easier to “sell” the proposal if it matches people’s exiting mental model (or at least, explains how the new commands sit within that model).
2 Likes
On the topic of existing installations shadowing pymanager’s python and py commands, is there a way to let pymanager prepend its own commands to PATH on first run?
That would reduce a lot of friction when introducing it to the general populace (“it just works”). I don’t think telling users to uninstall exisiting python installs (and potentially breaking virtual environments that are hardcoded to use a certain executable file location) is a good way forward. If a user later installs another python install and adds it to PATH, then that’s on them.