With this change of policy the foundation does not "have any control or influence over what WinGet does", one of the first class methods to install python.
WinGet and potentially MSIX have a glaring hole that should make this a no-no: programs installed that way don't work correctly via native Windows SSH server. If I remember correctly, the scenarios that fail are: installing using WinGet via SSH fails, updating using WinGet via SSH breaks the executable shims, and if Windows Store updates package, you can't use executable shims from SSH until reboot.
This is pretty terrible for offline deployment. An install manager is useless for offline systems.
For folks who don’t want any hassles, there’s WinPython. It’s a portable Python distribution à la Anaconda. The “whl” flavor includes a nice wheelhouse of packages that you can use as a flat index for your venvs.
rip to the .exe installer - honestly overdue, since python on windows has been a rite of passage in suffering for too long, and leaning into winget/store is the right call
For a while, HN has been almost exclusively my news source about tech on MS Windows. Every time I read about something happening in that awful place I give myself a virtual pet on the shoulder and let out a sigh of relief. Tech that's either unremarkable or even decent on Linux turns insanely hostile on MS Windows...
I can understand people locked into this system by their evil and incompetent management. But why would individuals unconstrained by corporate policies choose to use this? It's not just the system itself. It's like Microsoft only sets the stage, and then everyone using the system collectively tries to make it even more hostile.
Just to be clear, Python is doing this because they want to. Also, there is no reasoning in the post, which is odd to me. I have always used the exe to install Python and I didn't see anything wrong with it.
> But why would individuals unconstrained by corporate policies choose to use this
I know this might be incomprehensible, but some people, some of them even software developers, run more on their OS than just terminal CLI tools.
And for others the lack of customizability is a feature. You can't install a different desktop environment. You can't customize the task bar too much. Which also means you can't get your OS to a broken state as easily.
I have never broken my OS by installing a different DE in over 20 years of Linux being my daily driver, and multiple distros. I heavily customise panels to reflect current usage and hardware and I cannot imagine how this could break the OS.
They should honestly just instead back `scoop` as the default way to install Python on Windows. It's clean, sits nicely in userspace and handles CLI execution aliases elegantly.
Not a windows user so knowledge is a bit fuzzy, but I remember the one of the advantages of MSIX being that the actual installers have less system access, but not sure if the applications once installed are any different.
Yeah with MSIX, the security is better for end users, but the trade off is there's a lot less flexibility for developers (limits on custom installs, accessing registry, Custom Actions, etc.) This works out fine for most desktop apps, and MSI is still used and supported.
> To install using WinGet, the command is "winget install 9NQ7512CXL7T"
Is the package name on purpose?
MS decided to look at all good practices in package repository management and don't do them
Yes.
winget install ICURAIDI0TFU seemed unsuitable for production.
winget install 8NDEADBEEF9N offended some.
winget install 0%U#I#$#$$## had too much hash and blow for some US states.
winget install python3.11 was too obvious.
No?
In the case of 3.11 'winget install python.python.3.11' works just fine (Community Repository).
Hey, it's quite an improvement over GUIDs!
With this change of policy the foundation does not "have any control or influence over what WinGet does", one of the first class methods to install python.
https://github.com/python/pymanager/issues/287
I've been using uv to manage python with great success, but yeah, now that Astral has been aquired, it sort of makes me a little bit uneasy I admit.
WinGet and potentially MSIX have a glaring hole that should make this a no-no: programs installed that way don't work correctly via native Windows SSH server. If I remember correctly, the scenarios that fail are: installing using WinGet via SSH fails, updating using WinGet via SSH breaks the executable shims, and if Windows Store updates package, you can't use executable shims from SSH until reboot.
> Python install manager will automatically update within a day of an update being released
Totally something that someone in his right mind will not want to.
Also impatiently waiting for the day that the org will be blocked on the store so that the morons that decided that can be rewarded...
Also, how can you do an offline install?
This is pretty terrible for offline deployment. An install manager is useless for offline systems.
For folks who don’t want any hassles, there’s WinPython. It’s a portable Python distribution à la Anaconda. The “whl” flavor includes a nice wheelhouse of packages that you can use as a flat index for your venvs.
> To install using WinGet, the command is winget install 9NQ7512CXL7T.
so ergonomic!
rip to the .exe installer - honestly overdue, since python on windows has been a rite of passage in suffering for too long, and leaning into winget/store is the right call
For a while, HN has been almost exclusively my news source about tech on MS Windows. Every time I read about something happening in that awful place I give myself a virtual pet on the shoulder and let out a sigh of relief. Tech that's either unremarkable or even decent on Linux turns insanely hostile on MS Windows...
I can understand people locked into this system by their evil and incompetent management. But why would individuals unconstrained by corporate policies choose to use this? It's not just the system itself. It's like Microsoft only sets the stage, and then everyone using the system collectively tries to make it even more hostile.
Just to be clear, Python is doing this because they want to. Also, there is no reasoning in the post, which is odd to me. I have always used the exe to install Python and I didn't see anything wrong with it.
> But why would individuals unconstrained by corporate policies choose to use this
I know this might be incomprehensible, but some people, some of them even software developers, run more on their OS than just terminal CLI tools.
And for others the lack of customizability is a feature. You can't install a different desktop environment. You can't customize the task bar too much. Which also means you can't get your OS to a broken state as easily.
I have never broken my OS by installing a different DE in over 20 years of Linux being my daily driver, and multiple distros. I heavily customise panels to reflect current usage and hardware and I cannot imagine how this could break the OS.
90's called, they want your opinions on Linux GUI back
They should honestly just instead back `scoop` as the default way to install Python on Windows. It's clean, sits nicely in userspace and handles CLI execution aliases elegantly.
So now you're forced to use Microslop Store to get Python? At the very least they could offer .msix files to download and use.
"Use of the Store app or the MSIX package is recommended."
There's a big ole green download link on there for the MSIX lol.
MSIX is what ships on the store. And some devs just use it as an installer as well. By the way aren’t MSIX installed apps sandboxed?
Not a windows user so knowledge is a bit fuzzy, but I remember the one of the advantages of MSIX being that the actual installers have less system access, but not sure if the applications once installed are any different.
Yeah with MSIX, the security is better for end users, but the trade off is there's a lot less flexibility for developers (limits on custom installs, accessing registry, Custom Actions, etc.) This works out fine for most desktop apps, and MSI is still used and supported.