Yes, it would (unless they disabled the launcher during install). There’s no way around that, other than basically deprecating the old launcher without any replacement and telling people to never use py anymore.
You get similarly broken behaviour if you install Python 3.4 (before the last change to launcher installation) without turning the launcher off. It’s kind of the nature of installer changes that the new technology doesn’t interfere with the old one - and if it did, it would break the users who installed it on purpose because they wanted it.
Luckily, the launcher since 3.5 can be easily uninstalled on its own without affecting a Python install. So we will document that it should be removed if you want to use the newer version (see the proposed docs), and I’m probably going to add more helpful warnings if you py install with the old one, so at least if someone gets a recent old launcher they won’t be completely on their own.
Good catch, I missed updating that. (As a general rule, the PEP text is authoritative while the reference implementation - including the docs - are not.)
I also just noticed that GitHub doesn’t render tables in rst files, so if you’re reading the reference docs, it may be worth switching to the Code view.
But now that I know what the intention is, I’m appeased.
In that case, I also drop my objections to overloading the py command with new installation management functionality on the basis that the py command is deemed advanced usage anyway. [1]
I’m still not sold on the benefits of overloading py but it doesn’t bother me any more ↩︎
Yeah, the recommendation for other people’s docs was a very specific request, but it’s hard to frame it well.
The actual docs will get plenty of work done before this releases, I’m sure. But as docs, they’re reflective rather than definitive (that is, we’re allowed to change them later )
The PEP has now been submitted to the SC, though as mentioned I expect this will result in a PEP delegate being assigned and the discussion continuing.
I have also published another build to Release 0.1a6 · zooba/pymanager · GitHub. This one includes automatic updates (for the MSIX), and so when I publish new releases now you will receive them within 24-48 hours. I’m not totally sure whether this is a good idea at this stage or not, so I guess we’ll find out
If you installed the previous one (0.1a6) then you should get updated automatically within the next 24 hours (potentially only if you actually use it during that time). I’d love to hear if that works for anyone.
It’s still based on the NuGet packages. I’ve got the build scripts needed to convert old releases, but until I get an okay from the Steering Council I’m not pushing the needed changes into any main repositories, so it’ll just have to wait. You can rest assured that IDLE will be there eventually though, it’s just not in the NuGet packages and so not installed by the prototype.
(Apologies for posting first on the ideas thread - I got used to the green category and was skimming through old posts…)
Hello everyone,
Please find below my comments on this proposal.
First, I think it would be good to avoid breaking the “py” tool behavior by removing the python launcher and replacing it with the python manager. It will also break existing documention and by that I mean those outside of the python website.
If you really need a short name for the python manager then I’d suggest something like “pym”.
I’d also like to point out that in some companies, it’s not possible to install directly from the internet for security reasons, and that python is packaged so that it can be installed locally. So it’s important that it’s still possible to create these packages.
All the existing behaviours continue to work, and only some extreme edge cases (such as how certain shebangs may behave in certain circumstances) are going to change. Does this address your concern?
This is addressed in the PEP, by showing that the manager can be downloaded from python.org and installed offline (and is also available as an MSI for administrators), and the py install --download ... option to prepare an offline package on another machine. There’s also support for IT admins to provide an internal mirror of packages that will work exactly the same as the public one (provided they set it up right - documented better in the docs than the PEP, as it should be).
I’m reassured to hear that the compatibility with the python launcher will be kept (I did not have enough time yet to read the PEP in depth but right now I’ve seen the exec subcommand section and it looks fine.
As for the offline option, I’ll have to take some time to read the PEP in detail. We have an in-house solution for packaging that doesn’t seem compatible with the way the manager works. We’re also very rigid about the versions of python that can be used on workstations. So I’ll have to take a close look at that.
By the way I’ve just read the administrator installs section and I am a bit septic about the enterprise friendliness of ‘Installing a copy of Python for all users is no longer possible’.
I can see the flexibility for tinkerers on their own computer but from the enterprise point of vue we want to be able to lock down what users can do (e.g. we only allow the use of Python versions that still receive bugfix maintenance on windows workstations).
We also want to be able to force update of the installed package to the latest bugfix release as users will not update on their own (or at least not soon enough).
Yes, it’s a change for the better here I believe. Admins can control the copy of the install manager that is installed, and can override the feed it uses to choose runtimes to install. So you’d either allow it to be installed and set an alternative feed, or provide your own install of it.
That feed can provide exactly the options you want users to have, and can even reference your own builds of them if you want to exceed what we publish upstream.
Ultimately, our distribution from python.org is meant to be user friendly, not admin friendly. So we’re always going to allow per-user installs that avoid admin controls (and recommend blocking the PSF certificate if you really care to stop it) - users can do this themselves anyway. The ability to control the defaults is, I believe, a big step towards allowing this freedom while also allowing admins to help users do the right thing.
We also don’t discourage others from making admin controlled distributions, if that’s what they want to do. We just aren’t investing our volunteer time in producing them.
Yeah, I get this (I work with a team at my job who do this, too), but it is kinda counter to my point above. That said, py install --upgrade will update every installed version it can, so it’s much easier to stay up to date, and there’s the possibility of adding checks for updates in the future to prompt users when one is available.
The aggressive steering users away from system wide installations is one of my favourite things about this change. New users seemingly invariably select all user installs (like they’d do for any other application), not realise that a Python environment is supposed to mutable then wonder why pip is so addled with permission errors.
To everyone else, if this comment makes you want to discuss pip’s handling of unwritable environments, please just start a new thread (or join one of the hundreds of existing ones). We don’t need to discuss it here.
But yes, there’s no good reason for a user to select an all users install,[1] which is why I’m happy to steer away from it.
By definition, if you are installing things for other users, you’re an administrator. ↩︎
)
