Paul Moore <p.f.mo...@gmail.com> added the comment:
Thanks for the clarification. > In all the cases I've tested, regular Python install shows up first. If it's > not installed, the Store app shows up much of the time. This feels like the > right design (with the caveat about "much of the time" requiring changes > outside of our direct control), but without actually giving it to people in > all their messy configurations there is literally no way to be sure. Agreed, it does sound like it's probably the correct approach. But I'd strongly recommend that as much of the behaviour as possible gets documented as part of this change. There are a *lot* of projects out there that write code for Windows based on a relatively superficial understanding of all of the complexities that come into play here - most registry scanning code is based on guesswork and reverse engineering of how things worked before PEP 514 (I should know, I wrote rather a lot of it!!!) and plays fast and loose with even things like 32-bit/64-bit registry overlaying (it's late and I'm tired, sorry for not using the accurate term). Settig projects like virtualenv, tox, nox, pew, pipenv etc up for new bug reports associated with store installs, without any sort of guidance as to what's going on in the official docs, seems unfriendly at best. (I'm thinking of a section in "Python Setup and Usage" covering the store installer - that in addition to the changes in https://docs.python.org/3.7/using/windows.html#installation-steps needed to mention that there's now five installers available). > A regular install does not create "python3" and "python3.7" shortcuts on > PATH, so if you use those you'll prefer the store app. But we've never used > those, so there shouldn't be any change to existing behaviour. And I've never > really been opposed to adding them to the Python installer, I just haven't > done the work (and neither has anyone else) - I'd still be opposed to > modifying PATH from the traditional installer though, as all of those > problems remain. The "pythonup" project (https://github.com/uranusjr/pythonup-windows) creates versioned copies of python - python3.7.exe. Again, it's a non-standard project, so not technically our problem, but I'd be interested in how it would interact with the Store python. I do appreciate that we need to get the store installer out there in order to test things like this, and that initially at least there aren't going to be a huge number of people using the store installer over the traditional one (and likely vanishingly small numbers of people using both in parallel). But conversely, there's a class of problems that will be reported to other projects rather than to us, and I think we should be trying to support those other projects in dealing with this change, not simply leaving it up to them to find out about it (I doubt they'd even know to ask "did you use the store install or the traditional one" when diagnosing a problem). In general, I don't think we've done that great a job of publicising the various install options on Windows - we still get pip users trying to install packages into the embedded distribution, which they are using as if it were a standalone interpreter, and as far as I can tell essentially no-one knows about the nuget packages for Python. Let's not repeat the mistakes we've made previously with this new distribution option. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue34977> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
