Windows 10 has “python” command that redirects to the Windows Store | Hacker News Reader

Windows 10 has “python” command that redirects to the Windows Store

twitter.com

158 points_bxg1123 comments

I'm a developer who's never had to ship serious production systems with Python, but I have had to modify the occasional library or open source package. i.e. I know just enough to get myself into trouble...

I develop on a Mac where in theory everything should be easier:

* Comes with Python out of the box

* Platform has ubiquitous and wonderful package manager (Homewbrew)

And yet, 90% of my interactions with Python via the CLI involve it crashing because the version that the current thing I'm trying to compile or execute wants isn't the one the OS happens to be vending for it.

Some OSS projects suggest using things like pyenv to help. I don't know, it just seems to make things even worse for me because now even 'which python' doesn't tell me anything because it directs to some shell script shims that I can't parse or understand.

Python the language is wonderful, as are the libraries that exist for it.

Python the runtime/execution environment is actively hostile to users, and it's honestly keeping me from actually building anything real with it from the ground up.

I'm not surprised that Microsoft went with this approach to TRY to help it's users.

I'm also not surprised that Python devs are pissed because I've also been in those shoes where FINALLY everything is working, and you think you have that one version of python 2 and one version of python 3 both running and coexisting and everything you need to run runs, and then something small changes and WHAM the whole house of cards collapses.

But I wouldn't be angry at Microsoft, I'd be angry at the Python community for letting things get so bad.

I get it, but if you are developing on python, you should consider the "OS python" to be a completely separate thing you don't touch. The reason is that programs in your OS are using that python, and if you muck it up, you risk damaging your OS. Updating a package could stop your computer being able to log in (although that risk is only slight).

Developers should be using pyenv or similar (try Anaconda if you want "easy") and preferably one environment per project (so you can lock in library versions for the project).

I'd personally prefer the "OS python" to be more hidden, but I don't know enough about linux/mac inner workings to know if thats even a thing (maybe a libpython instead?).

But it is hard to understand if you aren't working with python all the time. I do basically just python, and still spent several years with outdated Ubuntu-shipped libraries before getting properly setup.

I would argue if not using the OS python is the correct way to do things then python by default should not install at an OS level. Installing in the OS should be left to the OS only and the default should be that python installs per project which special instructions for installing it as a default for a user and special special instructions for how to replace the OS level one.

I really wish this was the default for all languages but the majority default to "install in your system" and then I run into the problems you and the OP mention.

As it is, finding out/figuring out how to work around the default is always magic incantations and spells buried on page 947 of appendix G if you're lucky or else spewed around the internet in drips and drabs by unreliable and or outdated sources.

As an example I wanted to contribute to some conformance tests for some browser API. The test suite used selenium which uses python all of which wanted global installs. I tried for a few hours to get it to run with local installs but I failed to find the correct secret ritual to perform and after a few hours decided I no longer felt like searching for the correct oracle to enlighten me.

ps: For my particular needs a VM was not a solution

then python by default should not install at an OS level

Which is exactly what will happen later this year(?):

"The older Python language, version 2.7, is being deprecated in macOS 10.15 Catalina and won’t be included in macOS 10.16. The same goes for other UNIX scripting languages."

https://www.macobserver.com/analysis/macos-catalina-deprecat...

I think this is a mistake on Apple's part, fwiw.

Relying on tools that come with the system puts you in a bad place if you want to run different versions of the tools than the system provides.

It's really better for everyone if the base OS contains less, and you get more from the package managee (of which there are several to choose from on MacOS).

If Apple wants to provide installable tools on the OS install media, that's fine, of course.

I once shipped a python script with a dependency on the requests package, and installing that on the customer's system caused an outage on their production server with 1000s of users because of a permissions issue, that wasn't present in their and my test systems.

So, no more "use the system python" for me...

what a nightmare

Agreed. The OS shipping version is not a thing in every single language I've been working with. It's either outdated or not the version my project needs, and what if I need many different versions for different projects?

I always use a language manager for Elixir, Erlang, Node, PHP, Python and Ruby, either the language's usual one or asdf. I'm even using different versions of databases, usually with docker. Java is somewhat easier to deal with, unzip in a directory and set JAVA_HOME but I'm not working much with it so I could miss some nuances.

> * Comes with Python out of the box

Not for much longer.

"Scripting language runtimes such as Python, Ruby, and Perl are included in macOS for compatibility with legacy software. Future versions of macOS won’t include scripting language runtimes by default, and might require you to install additional packages. If your software depends on scripting languages, it’s recommended that you bundle the runtime within the app."

https://developer.apple.com/documentation/macos_release_note...

I think this is a good thing. I've had regular problems with Ruby and Python versioning on macOS.

I really wish Python's developers weren't hellbent on breaking backward compatibility.

If you are distributing to someone who is not a developer Pyinstaller or py2exe are your friends on windows. Build your exe, and wrap it up with a MSI installer using wix.

As a developer, I would qualify this even further by specifying someone who is not a developer who works extensively with Python.

> * Platform has ubiquitous and wonderful package manager (Homewbrew)

Is this the case? I thought Homebrew was considered fairly mediocre compared to more established package managers on (eg) Linux systems. But I've never been required to use a Mac, so my firsthand familiarity is limited.

Even ignoring any potential issues with Homebrew, it has the inherent disadvantage that every macOS package manager has in that it does not ship with the system by default.

It's extremely slow so even when it works I'm not satisfied

> Platform has ubiquitous and wonderful package manager (Homewbrew)

Probably "wonderful" is subjective (Homebrew to me is far from being a wonderful piece of software), but "ubiquitous" is factually wrong. MacPorts, even though less popular than Homebrew, has a large userbase.

> Some OSS projects suggest using things like pyenv to help. I don't know, it just seems to make things even worse for me because now even 'which python' doesn't tell me anything because it directs to some shell script shims that I can't parse or understand.

Quick tip:

    pyenv which [python,pip,...]
    pyenv help

The shimming of Pyenv can bite you sometimes, but for the most part it has the tools necessary built in to help you figure out your env.

> it just seems to make things even worse for me because now even 'which python' doesn't tell me anything because it directs to some shell script shims that I can't parse or understand.

I understand it’s another layer and for someone not working in it daily, it’s hard.

Some info, the command

    which python

Wouldn’t tell you much anyway. It would just return something like

    /usr/bin/python

Reading a binary wouldn’t lead to much either. If you’re trying to get the version of python, this still works,

    python --version

Pyenv also has this command,

    pyenv version

That also works with pyenv virtualenv (if you’re using it)

If you want all versions installed,

    pyenv versions

Helpfully, Python 3.4 switched from writing --version output from stderr to stdout, so you need capture both :-|

I’ve had similar experiences with Ruby (and Rails). I loved the language and it paid the bills for a large part of my career. But the tooling and distribution are abysmal.

I can count on one hand the number of times “bundle install” has actually worked on the first try. Getting an existing project working on a new machine (sans docker) is an exercise in frustration.

For non-system users, there's no good reason to use python outside a virtual environment now, and IMO the devs shouldn't encourage it.

Perhaps python should issue a warning if used outside a virtual environment, unless that warning is deliberately suppressed by a flag? That would be worth a point release on all older versions.

How's the situation with python packages that have native code parts? Previously they had to be compiled during installation, which wasn't easy on Windows.

Debian fixes this issue by having dist-packages for OS vendored packages and leaving site-packages as a customizable sandbox for the user. This makes it easy to install things without stomping on OS packages.

I don't call myself a Python dev, but work with it enough... and I am tripped up by environment issues on a weekly basis. (Not just on my main workstation, either.)

I never have issues with my Python environments, and I use either requirements, venv or pipenv, depending on the project.

And I use it on Windows and Linux, server and desktop. You might be interested in: https://snarky.ca/what-the-heck-is-pyproject-toml/

> And yet, 90% of my interactions with Python via the CLI involve it crashing because the version that the current thing I'm trying to compile or execute wants isn't the one the OS happens to be vending for it.

Do python releases introduce backwards-incompatible changes (ignoring the 2.x/3.x divide)? Would it not be as simple has making sure you have the latest runtime?

This issue is largely OS X related rather than Python-related per se. OS X ships with vendored copies of many common Python libraries which you cannot update, and so if you need to use newer libraries you have to install them in some other location and fiddle with the path to make sure your versions are loaded before the OS X versions. Because the versions included in OS X (including the version of the Python runtime) are pretty old almost everyone ends up doing this.

In theory homebrew takes care of the whole thing for you but, in practice... as an only part-time OS X user I have run into a lot of problems with the path getting set in various ways that end up in various copies of the Python interpreter or library paths getting loaded, resulting in runtime errors due to library versions being inconsistent with the interpreter version or expected libraries not being loaded...

A further complication is that, the specific way that Apple vendored a set of python packages, it is possible but not particularly easy to add new packages to the OS-provided Python runtime, so most users, if they want some package that Apple didn't include, seem to end up installing a whole new environment just to get that package, even if the OS-provided environment were otherwise acceptable to them.

It's a very real problem and very frustrating, but I'm not quite willing to blame it on the Python ecosystem because it seems to be pretty much a result of Apple's decision to ship an interpreter and set of libraries that most users will end up being unhappy with. Anecdotally at least I run into these issues a lot less on Linux because even with fairly stable distributions (e.g. RHEL7.5/8) the included interpreter and library are more recent and the package repositories include most of the Python packages you would want, maintained to match the OS interpreter version. So while some people do end up using virtual environments it's less necessary than it is on OS X, where it frankly seems near impossible to do anything without installing a whole second Python environment and munging paths.

An extra complication is that, as a casual OS X user, it seems to me like OS X terminal emulators and tools are more likely to munge with the path than Linux terminal emulators and tools, so even if you get everything set up "just right" you end up having it not work properly in certain contexts like plugins because something has modified the path for some reason.

Edited to expand that, I guess what I mean to say but failed to articulate, is that the fundamental problem here (in my opinion) is that OS X ships with a Python distribution but not with a package manager. That's the fundamental difference from Linux where these problems are much less common. Third-party package managers like Homebrew and Macports are used, and in order to have full control of the Python environment they have to install a whole second copy because they are not allowed to tamper with the OS X Python environment. This pretty inevitably leads to frustration. The best solution would seem to be for Apple to provide some kind of "first-party-ish" package management functionality, perhaps something like Chocalatey which is not a Microsoft product but is built on Windows-provided primitives, so that the package managers that users are actually using can play nicely with the OS X Python environment.

An extra complication is that, as a casual OS X user, it seems to me like OS X terminal emulators and tools are more likely to munge with the path

This might be a function of the casualness rather than the tools. Here's a thing to check out on OS X:

    man path_helper

I didn't know about this for ages and it makes your path life much saner - at least you'll have some idea where seemingly magical paths come from. Personally, I use it for everything and don't let other profile scripts eff with the global path at all.

You set up your personal shell paths by adding files to /etc/paths.d/?

With neither shame nor ruth. Is there some non-aesthetic reason not to?

No! Well other than not having your whole shell environment in your dotfiles. It just wouldn’t have occurred to me.

Linux has often had the same issue. The problem is the OS relies on system installed Python and package versions. If you, as a user, upgrade Python or those packages the OS may not gracefully handle them. In Linux you can end up with an unbootable OS. I'm not sure if you could blame Python devs or the OS devs (or the user).

Homebrew can help with distinction, letting the user install to `/usr/local/bin/python` while the OS continues to use `/usr/bin/python`. My personal solution is to install Python packages into my homedir (--user) or use virtualenvs. This also helps when six months from now you want a "clean" setup.

I've pushed any organization I've worked at who heavily relies on Python to decouple Python from the OS because of this and so OS updates can be independent of Python updates.

> An extra complication is that, as a casual OS X user, it seems to me like OS X terminal emulators and tools are more likely to munge with the path than Linux terminal emulators and tools, so even if you get everything set up "just right" you end up having it not work properly in certain contexts like plugins because something has modified the path for some reason.

GUI apps not being able to access $PATH is a big one, I have found.

So it sounds like more of a packages thing than an interpreter thing; basically "DLL hell" all over again.

Setting aside all other axes of comparison, it sounds like Node really learned from Python with regards to this problem. Install Node itself, do an NPM install, and you're golden.

Until your global installs get stale/conflict with new global installs. npx is pretty handy for this problem though.

I would say the key is not relying on global installs. By default all NPM dependencies are installed locally alongside the manifest. You use more disk space, but disk space is cheap these days.

Clearly you have never found a random python script on the internet that does exactly what you need and tried to run it. It's a nightmare every single time.

Could be worse, try to run a C++ project next time! But yeah, the same applies to Ruby, Node, even C# (msbuild or CSX) and PowerShell modules. You have to know enough to know enough to get started.

About the only thing that reliably works besides "install Docker" is getting a bash shell going and pasting in a curl link, assuming your operating system is supported by whatever it is. That said, a close runner-up, that doesn't require bash and curl to be installed, would be Node's npx. Just run it, and "it works" even if whatever it is isn't installed. (Unless whatever it is doesn't have a precompiled binary for your system published and you then need to install CMake and compile tool chains like Xcode or Tools for VS)

Just a example for a breaking change between Python 3.7 and before: https://stackoverflow.com/q/51196568/6885801

It is because Python 3.7 makes "async" a reserved word, which was a valid identifier name before.

py34 asyncio was provisional (read: experimental, API in flux). It was very clearly labeled as such in both py34 and py35.[1][2] In py36 it was no longer provisional, but async/await syntax was established in py35 and asyncio.async was already deprecated back then. Using an example of a clearly experimental and evolving feature as breaking backwards-compatibility is disingenuous.

Now, there are actual backwards-incompatible changes that aren't made after at least two versions of deprecation, but those tend to be low level and subtle.

[1] https://docs.python.org/3.4/library/asyncio.html

[2] https://docs.python.org/3.5/library/asyncio.html

More on provisional API:

https://docs.python.org/3.8/glossary.html#term-provisional-a...

> A provisional API is one which has been deliberately excluded from the standard library’s backwards compatibility guarantees. While major changes to such interfaces are not expected, as long as they are marked provisional, backwards incompatible changes (up to and including removal of the interface) may occur if deemed necessary by core developers. Such changes will not be made gratuitously – they will occur only if serious fundamental flaws are uncovered that were missed prior to the inclusion of the API.

I think you misunderstood maple3142 comment: he is only saying that from Python 3.7 onward you could not use "async" as an identifier in your code, as it became a reserved word.

So maybe you were using "async" as a variable name, or as a function name in your code, and suddenly that wouldn't work anymore. It definitely is a backwards-incompatible change, and that has nothing to do with provisional APIs.

Since I have never use "async" as an identifier in my own code, I have no idea if warnings were issued, though probably?

Reserved words are introduced into languages over time. This is how languages evolve and hardly Python-specific. (Example: Rust added async/await keywords relatively recently.) You either stick with an old version or deal with it.

gp specifically links to a SO question discussing asyncio.async breakage, which would be considered API breaking except it was specifically provisional.

Even after the 2.x/3.x debacle, it's not as simple as keeping everything current. For example, until very recently, Tensorflow would work on Python 3.7 but not on 3.8. TF is just one well-known example, but version incompatibilities are common enough that many Python devs keep multiple virtual envs.

I've had a very similar experience on Linux. Love to build projects with Python, hate to use other's Python apps (unless they're packaged, in which case I don't even have to know).

    pythonX.Y -m module

homebrew and mac application management is far from wonderful. you should just start using pipenv.

conda

> I'm not surprised that Microsoft went with this approach to TRY to help it's users.

This approach doesn't help--it makes things worse. I see this occasionally on Linux as well. A novice programmer will think: My program depends on programs X, Y, and Z, and if they're not there, I'll download them from the Internet to make things easier for my user.

Aside from being a major security hole, this just makes a mess. The user has no idea of what's going on, and it's 10x harder to debug when something goes wrong.

I do relate to your pain. For starters, I'd recommend not using a Mac for Python development (or really any development). If you must, something like a VirtualBox machine running Linux would be good. But probably better to just make a Linux instance in the cloud.

It takes a lot of IT knowledge to get a Python script to work properly on Windows. And yet somehow you figured out a way to blast Microsoft for trying in good faith to help out the Python community. And it was done in concert with the Python community, so it's definitely not "fake".

This makes me sad.

Agreed. On the beloved GNU/Linux distros, when you "$ python" and it's not installed, Package Kit will recommend you to install it through the native package manager (like apt or dnf). This is literally the same thing. Windows Store is the package manager for Windows.

The difference is implementation. GNU/Linux systems do not hijack the 'python' executable. If such an executable is on the path, they will use it. If Python is not installed a program can check the path and see that Python is not installed.

It is only when the user tries to run python on the terminal that the system (I presume the shell) detects that the program does not exist, and it then executes another program to inform the user.

If you put python as the #! interperator for a script, then bash will complain that interperator cannot be found.

If it is used as a command as part of a script, then bash does not call the normal command-not-found program (which advises you to install it), but just prints to stderr that the command was not found.

Windows doesn't "hijack" the python executable either. This stub should be a low priority in your PATH and the official Python installers should take higher priority when they install. It's basic PATH management, with much the same environment variable management issues on Linux as it is on Windows.

It's unfortunate that so many machines that this poster is working with are getting malformed PATH variables with the priorities out of order, but it should be a simple fix to the PATH to correct.

It should also probably be noted that the Microsoft/Windows Store installed version of Python is the official Python.org release. (It's CIed, and CDed directly from Python.org just as with any other release binary.)

Even with correct PATH management, Windows still hijacks the command when python is not installed; that it the mechanism it uses to advise you to install it. Linux distributions use a different mechanism that maintain the expected behaviour of there not being any program/comnand called "python" when python is not installed.

Windows solution in this case is a lazy hack that makes the system more brittle.

As an aside, Linux distributions tend not to have this sort of PATH management issue because (for better or worse) they tend not to modify PATH when installing software.

Good luck running dnf without python!

  $ head -1 /usr/bin/dnf
  #!/usr/libexec/platform-python

RHEL 8 uses a separate internal copy of Python for dnf, so yes, you can run dnf without the package which provides the python command.

It's "fake" in the sense that that program cannot do anything that one would expect the program named python to be able to do. However well intended, it's a terrible idea.

This actually reminds me a lot of DNS servers that, when presented by an unknown name, will redirect the user to an ad page, or perhaps some page explaining how to otherwise look for the name. It doesn't help--it makes a mess. Just say "not found".

You don't think the "yet somehow figured out a way" blame maybe lies with Microsoft for breaking it instead of the user? Nice idea, problematic execution it seems.

Maybe Microsoft was trying to "help out the Python community". But what they did was just awful. Python is, by far, the most popular system glue language in the world. People have spent decades writing it and running it on windows. It has years of culture built up around version detection and deployment strategies, so that developers understand how to get "python" and exactly what they are getting when they do.

And now all of a sudden you run a "python" script and you get something that is not a python interpreter.

That's just insane. I don't doubt Microsoft's motives, but good grief is this dumb.

Install Python --> Run script?

Python adds itself to PATH on installation.

What did you have trouble with, and when was that? Python 2 used to not add itself to PATH iirc, but that was years ago.

Even for dependencies, I haven't had any trouble in many years, and I've supported people of all skill levels on half a dozen OSes.

Even the most complicated ML stuff that pip can't do alone, conda takes care of in seconds.

Python has made computing easier than any other single tech in my career, I think.

If you have some particular frustration with Python on Windows maybe I can give you some tips?

>it takes a lot of IT knowledge to get a python script to work properly on Windows

I know this wasn't the point of your post but as an aside - I am not a programmer but am very familiar with computers and I have so much difficulty running Python scripts that I just don't try any more and if that is the only solution to a problem I am having I just write it off as impossible. it's extraordinary to me how user unfriendly it is.

These days it's easier for me to pull a python docker image, then to figure out how to install it on my system.

Only for python do I develop inside docker.

The situation is unfortunate, but the grievance is legitimate. I regularly have to provide tech support to users when shell scripts fail with a terse "Permission denied" trying to invoke Python because the Windows Store launcher is higher on %PATH% than the Python that they just installed.

There's an actual term for this "fake" command: it's a stub command. Stub commands are by no means a new concept; for instance, on macOS many CLT commands are stubs (that prompt CLT installation), and IIRC the java family of commands in /usr/bin are stubs out of the box, too.

The real problem, or the claimed problem, is

> Windows 10 puts a fake python/3 executable in the path, ahead of the actual python.

(Emphasis mine.)

Somehow I'm on the slow ring and I'm not affected by this; the stub is definitely not ahead of the actual python. Why? Because C:\Python38\Scripts and C:\Python38 are way ahead of %LocalAppData%\Microsoft\WindowsApps (where the python.exe stub lives) on my PATH. When you install things naturally they prepend themselves to the path, CPython (or any python) installers included. Begs the question: what kind of geniuses put third-party paths after system paths, then bitch about breakage?

Edit: Upon further inspection of some complaints, I think what Microsoft should do is fixing then teaching people proper PATH management on Windows (which is terrible), since apparently all the top google-surfaced tutorials ask you to append to PATH, which opens you up to this kind of self-inflicted problems. (Clicking on "New" when editing PATH creates a new entry at the end; obviously doesn't help.)

CLT = Command-Line Tools, for those unfamiliar. (Unfortunately, I can't find an official link that's not behind a developer.apple.com sign-in.)

https://developer.apple.com/library/archive/technotes/tn2339...

Ok but what purpose do stub commands serve? What user is smart enough to be running command line tools but also too stupid to figure out how to install Python? Even if you did want to tell users how to install it you could just do it the Ubuntu way and make it a part of the error the shell throws when it can't find the program. If a program is not installed the expected behavior is that trying to run it leads to some sort error, not a fake program that engages in completely different behavior. If I see /usr/bin/python on my system then I'm going to assume that Python is installed. There's no point in subverting that expectation.

A lot of non-technical users are told to run this, run that in the console to solve random problems all the time. When they get an error they don’t try to interpret it, they get all confused and send you a screenshot (that behavior isn’t even non-technical user specific). Popping up an actual solution where they could install in a few clicks is actually welcome.

I would also think that people who are smart enough to complain about this are smart enough to understand path resolution and no fuck up their PATH, but here we are. Who would have guessed.

This isn't about PATH resolution, this is about pretending to have a program installed when it isn't. As other comments have pointed out, this "actual solution" also fucks up any Python script you try to run because nobody writes scripts thinking "what if python isn't actually python". What's next, selling a car that looks like it has an engine, but on closer inspection actually only has a flyer for the closest mechanic under the hood? Should I check if my plane actually has wings instead of cardboard cutouts made to look like wings every time I take a flight too?

If the python version from the Microsoft Store is installed the path is not changed. Instead the "stub commands", in Windows terms they are app execution aliases, now point to the python version installed by the store. In fact additional app execution aliases are created for other variations of the python command name along with ones for idle and pip.

That was a weird experience when I started using MacOS. "Why are we faking that Java and git are already on here?"

This really irked me when I found out because I spent longer than I care to admit diagnosing why a script I wrote seemingly did nothing.

I'm not sure if it's different now but when I had just installed anaconda python, and ran a script the usual way (`python foo.py`) it just did nothing (not even open the store page).

My memory might be a little hazy but I think not even changing PATH order of precedence made a difference. I had to find a sub-sub page in the modern settings app to disable the magic store hook.

I agree with some others here: I'm fine if I'm suggested a solution to a missing command but when that hook overrides a valid installation I have a bit of a problem :|

This actually points out what I think is a problem.

The Windows Store is no longer only sandboxed apps.

I wanted to install the Line App (I live in Japan and everyone uses Line and I hate typing on my phone). I have both a Mac and a PC. On Mac I go to the Mac App Store and install Line. I know (believe?) that the app is sandboxed and short of OS bugs can't spy on me.

I thought Windows Store was the same but then I saw Python on there and was like "wait a minute, that can't possibly be sandboxed on Windows". So I investigate and ... yea, many apps are not sandboxed. If you look at the Line App (or WhatsApp or Python or FB Messenger) or many others they list

> Access all your files, peripheral devices, apps, programs, and registry

Which if you dig further Microsoft says

> Access all your files, peripheral devices, apps, programs, and registry: The app has the ability to read or write to all your files (including documents, pictures, and music) and registry settings, which allows the app to make changes to your computer and settings. It can use any peripheral devices that are either attached or part of your device (such as cameras, microphones, or printers) without notifying you. It also has access to your location, and can use platform features, such as location history, app diagnostics, and more, which are denied to most Store apps. You can't control most of the permissions for this app in Settings > Privacy.

This is a half-baked idea by Microsoft, one many of us in the Windows community tried to warn them about last year [1][2] with no apparent success. (One big problem is that build systems/various scripts tend to look for a callable python/python3 to determine if python is installed. Calling out to this stub eats input yet outputs nothing, leading to lots of confusion.)

You can turn all Python aliases off by navigating to Settings > Apps > Apps & Features > App execution aliases. Alternatively you can Start search for "aliases".

[1] https://twitter.com/WithinRafael/status/1171339229583962112

[2] https://twitter.com/BruceDawson0xB/status/117089849987067494...

Done in collaboration with the Python community.

Is that true? Is there some sort of call for comments from the Python community on this? (Genuine question!)

Yes, it was even presented at PyCon.

https://devblogs.microsoft.com/python/come-meet-microsoft-at...

"Steve Dower - Python on Windows is Okay, Actually - PyCon 2019"

https://www.youtube.com/watch?v=uoI57uMdDD4

And is part of official Python documentation, as mentioned by others on this thread.

I'll take your word for it, but given how disastrous this feature has turned out, I'm skeptical. Presenting at a conference is unrelated to soliciting actual feedback.

At any rate, what are you doing about it now? Hopefully nixing the appinstaller execution alias?

the Windows Store is the official way to install Python on windows.

https://docs.python.org/3.7/using/windows.html#windows-store

Original Blog post from last year

https://devblogs.microsoft.com/python/python-in-the-windows-...

Really? That seems to be the "official" Microsoft way of installing Python3. For those who'd rather go straight to the source (should be everyone), try this, instead:

https://www.python.org/ftp/python/3.8.2/python-3.8.2.exe

No?

https://docs.python.org/3.7/using/windows.html#windows-store

>The Microsoft Store package is a simple installation of Python that is suitable for running scripts and packages, and using IDLE or other development environments. It requires Windows 10, but can be safely installed without corrupting other programs. It also provides many convenient commands for launching Python and its tools.

It is just "one" method of installation, and not even mentioned at the top of the page. The page also says

> Note The Microsoft Store package is currently considered unstable while its interactions with other tools and other copies of Python are evaluated. While Python itself is stable, this installation method may change its behavior and capabilities during Python 3.7 releases.

It is "an" official method, not the preferred official method, and most certainly not "the" official method.

That note was for Python 3.7, as of Python 3.8 the note is gone.

https://docs.python.org/3.8/using/windows.html#windows-store

So what? Some Linux distros will suggest installing a missing program if you run it via terminal and it's not installed.

> and it's not installed.

is the key difference here, as the submitted tweets clearly point out.

I use Ubuntu, one gets (something like) 'you can install with apt-get install missing-program'.

I've often wished it offered to do the install; I guess it doesn't because that might break apps trying to call the non-installed program, and messing with history/clipboard is not so good usability wise.

I wonder if there's some other built in buffer, or whatever, that could be used to achieve this? So, for example, it could say "press ctrl-alt-v to paste that command now" but still end the program so that a calling program can be sent a "failed to run code"?

Hard to imagine that this is some nefarious plot when Microsoft also provides one of the most popular Python editors (Visual Studio Code) and an excellent Python extension for it, and makes appearances at Python conferences etc. It seems more like a garden variety screwup.

And Python is supported as a first class citizen in Visual Studio.

This is part of a strange pattern of Windows aliasing popular Linux commands to things that do something completely different.

There is also "bash", which launches the WSL and "curl", which aliases to a powershell command with completely different arguments.

I ranted about this to my group of friends a while ago. I usually explicitely state `python3` when running scripts from the command line in linux and macOS. On my Windows machine I recently installed python for a mini-project and forgot to create a symlink so I could use python3 as a command. I then launched a script (which was working perfectly fine when run via VSCode) from CMD with `python3` and nothing happened. It took me quite a while to figure out, that python3 invoked the stub comman, which did nothing at all when called with a script as parameter. No error, no warning, the store page didn't open. Just empty output

Yep, it's real. Nice one, MS. :eyeroll:

  Directory of C:\Users\user\AppData\Local\Microsoft\WindowsApps

  01/15/2020  04:23 PM                 0 python.exe
                 1 File(s)              0 bytes

  Directory of C:\Users\user\AppData\Local\Microsoft\WindowsApps\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe

  01/15/2020  04:23 PM                 0 python.exe
                 1 File(s)              0 bytes

This made think of one of my favorite Pycon talks by David Beazley called "Discovering Python":

https://www.youtube.com/watch?v=RZ4Sn-Y7AP8

The premise is David got locked in a vault with terabytes of tangled source code on CD-ROMs, no network connection, no ability to bring software in or out, and just a bare Windows machine, and and the story goes from there...

Short of including a full Python installation in the base OS, what Microsoft is doing is a great idea. However, it seems like in some cases your PATH might get in the wrong order which can cause scripts to fail. I haven't encountered this personally and I've used Python on several different Windows 10 machines, each with the full version of Python installed from the website. Bugs happen, and path issues are easily fixed.

This would be a violation of the advice in PEP 394, except that PEP 394 only applies “to Unix-Like systems”.

https://www.python.org/dev/peps/pep-0394/

Basically, the Python core team suggests that the “python” executable/command be set to one of the following:

- python2,

- python3,

- not provide python command,

- allow python to be configurable by an end user or a system administrator

It would have been much better, IMO, for Windows to do nothing here. A Microsoft-blessed Python installer from the Windows Store could actually serve a positive purpose distinct from the official installer at python.org. That would be to support python2 and python3 side-by-side cleanly.

It might nicely install Python 2.7.18 at the python2 executable, and install Python 3.8.2, as well, and have python/python3 refer to 3.8.2 and beyond.

This would match an Ubuntu 20.04 system with python2 installed, and with python-is-python3 installed, which is, IMO, how a system should be configured if it needs to have python2 around for backwards compatibility, but wants the “system/default python” to be python3. And it’d make sense for Microsoft to do that since Windows, above all, is a system with a deep respect for backward compatibility with old tools. But, that isn't what they did.

Instead, this stub forwarding to the Windows store seems like the worst of all worlds. I am not really sure what problem they are trying to solve and for whom. If you are the kind of Windows user who opens cmd.exe and manually types in “python” into the black terminal window, are you the kind of Windows user who won’t be able to figure out how to open a browser to the official installer on python.org? Doubt it. Meanwhile, the stub likely breaks existing code, even code that may just be running “python -V” to see what version is installed at that path.

And apparently the Microsoft-blessed Python installer is just a python3 install (perhaps old), with no thought to python2 and backwards compatibility for old python scripts for Windows? Hmph. This doesn’t seem like an improvement over “do nothing”.

Didn't OS X do this with some CLIs, you'd type a command and got prompted to download Xcode..

Sounds familiar, but Xcode does actually provide a bunch of CLI tools...

I think it’s when you have to download the Xcode CLI tools that many packages rely on. But you do it once and you never do it again.

Definitely not equivalent situations.

The only difference is that it's more finely grained? I don't see how it's completely different

> But you do it once and you never do it again.

Well other than every time there's an Xcode update.

Yeah, Java and git in my experience. There's a dumb chain of symlinks to where they really reside.

Actually a symlink to xcselect, which looks up the command based on the current developer directory.

I'm fairly sure that if you install Python using the official installer and select the "Add to PATH" option that the actual executable will be used. I'll check later in a clean VM to confirm and update this comment.

The problem is that MS's python can end up taking path precedence even if you install via the installer, I've hit this before. It's Just A Bug, one that I'm sure that Microsoft would be very happy to fix if folx complained to the right people. The stub python.exe could very easily search PATH to see if it's getting put first and delegate, or the official Python installer could recognize and fix this

Why not just include python with Windows? They could take the opportunity to update it with their biannual Windows updates. Otherwise not offer any support for it if they wouldn’t like to.

Which version of Python would you bundle? The community can't even decide on a runtime.

This sort of mess caused Apple to ship Python 2.7 with OSX for 10 years and will stop bundling it at all in future [1]

[1] https://developer.apple.com/documentation/macos_release_note... (search for python on this page)

Because they would have to support that version of python for the life of the OS...regardless of what happens from the Python community.

Once you install python, is this redirection removed? If so is it only removed if you install from the Microsoft store, or also from a standard install?

The redirection is done by a low-priority PATH. Both the Store install and the "standard" install (both of which are built/maintained/managed by Python.org, fwiw) should install at a higher priority PATH. PATH bugs are just hard to entirely avoid, but PATH management is relatively easy.

(One big for instance is that System PATH and User PATH are concatenated and that the combined PATH when it exceeds a certain character limit sometimes causes subtle bugs like this one. People unfamiliar with Windows-specific PATH issues might not realize that issue.)

This is not 100% accurate. The "standard" install will place the installation directory higher in the PATH priority.

The store version doesn't modify the path. Instead it creates app execution aliases for the executables it installs. As of version 3.8.2 it creates the following app execution aliases: idle.exe, idle3.8.exe, idle3.exe, pip.exe, pip3.8.exe, pip.exe, python.exe, python3.8.exe, python3.exe, pythonw.exe, pythonw3.8.exe, and pythonw3.exe. These can be found in the %LOCALAPPDATA%\Microsoft\WindowsApps directory. Prior to installation the python.exe and python3.exe app execution aliases in this directory will launch the Microsoft Store. After installation of the "store" python they will actually launch python.

Python needed a major technology vendor with political will backing it.

Well, Microsoft wants to train open source developers to use the Windows store.

The whole install gets more and more complex. I've never had a problem when Martin von Loewis was still in charge of the installer.

The Python team themselves were just as interested in being in the Microsoft Store. Python prides itself on trying to be an easy to install language accessible to a wide variety of users.

MS is doing a good job of making me move the *nix lately. I can't even _open_ Windows store anymore, let alone check out their python stunt.

I genuinely don't understand some decisions Microsoft has made with Windows 10. The unavoidable telemetry / updates / ads, this Python thing, etc. are just so different from what I want an OS to do.

I can only assume that I'm somehow outside of Microsoft's target market and just don't realize it. But is there really a sizable fraction of computer users that want an OS to unavoidable behave like this?

> I can only assume that I'm somehow outside of Microsoft's target market and just don't realize it.

If you care about stuff like this you are not inside the target group.

> But is there really a sizable fraction of computer users that want an OS to unavoidable behave like this?

Nobody wants telemetry specifically, but it indirectly (provided somebody smart is receiving it, which is arguable in MS's case) benefits the average user by detecting their preferences and issues.

Updates are easy to argue for. Barely anobody will update their system on their own because they just don't understand the security implications. The people who understand them will probably all agree that getting people up to date quickly is important (you could argue better education could make a difference here, but that is so much effort, would hassle the user more and wouldn't reach everyone).

Ads are harder to argue for, but you could argue for them as a valid method of financing an otherwise free system (it was always a relatively transparent MS strategy to do this).

... But even without ads Windows is something I have a hard time tolerating in general. The version I use at work has most of the explicitly user-hostile things disabled and is still plenty infuriating.

Yes. My last Windows machine just died, and I'm migrating the last few Windows things to Linux. Have to use Wine once in a while. I don't plan to replace the Windows machine. It's so unnecessary today.

I've tried to do this multiple times, and yet I have always kept either a Windows machine or (more often) a Mac for a bunch of things. (e.g. Keynote; Outlook in a corporate environment; etc)

I loved it in the past, but now I simply don't have time or willingness to spend hours to configure drivers, etc, or do my own system maintenance.

My dream is a laptop with a solid linux distro, maintained by a company that doesn't die too easily, with a 3-5 year maintenance guarantee (kind of Ubuntu LTS, as a concept, but for laptop use, not server), where everything works, including a (possibly amazing) trackpad.

The other thing is: Mac's trackpads are absolutely the best in the market. That single item is responsible for a big chunk of my productivity boost. When I use a non-Apple trackpad on another laptop, I feel my productivity goes down significantly. I guess twenty years ago it was being able to use vim and bash properly :) - but not today, not anymore, for me at least.

Anyway, all of this to ask: what laptop are you using to run Linux?

Edit: forgot to add that I've been looking at System76 and Pop OS, but somehow they failed to convince me (together, or separately).

Laptop? I use a desktop machine. Better ergonomics and a much larger screen.

Got it.

I think the "unavoidable telemetry / updates / ads" are more about making money for msft than what the users want. Dunno with the Python thing - maybe just a screw up?

Yes they are definitely overstepping their bounds. It feels less and less like an OS a power user can rely on. Unfortunately Mac OS is so opinionated it might be worse. But Linux doesn’t have the same ecosystem for games and streaming doesn’t work for some services. It seems there is no harbor from the storm these days...

Nadella IT cells are downvoting heresy again. But I must be wrong, since the HN guidelines say this never happens.

Reply on news.ycombinator.com