3 ms·
It's gotten a lot better, but we still hit tons of issues with users who don't know what Python version they installed their application in. Oh and of course ou
by a_cool_username 6y ago
It's gotten a lot better, but we still hit tons of issues with users who don't know what Python version they installed their application in. Oh and of course our "binaries" in Scripts/bin don't seem to show up in the PATH by default. So I get to tell people "py -3.8-64 -m foo" on windows, "foo" everywhere else.
This gets much much worse when a new version of Python comes out and we don't support it yet (because of the build system issues I mentioned). I spent several weeks teaching people how to uninstall 3.8 and install 3.7 before we finally got a functioning package out for 3.8.
- sergeykish 6y agoI like Mozilla build system on Windows, you click "start-shell.bat" and it runs console. Python, mercurial, rust - just works, never checked PATH. https://firefox-source-docs.mozilla.org/setup/windows_build.html https://firefox-source-docs.mozilla.org/setup/windows_build....
- ptx 6y agoSure, but telling people to run "py -3.7" seems a lot easier than walking them through uninstalling and reinstalling Python, as you would have had to in the bad old days. It's reliable and consistent and doesn't depend of what's installed where or how it's configured. If you run "py -3.7 -m venv my_env", it just works, always, with no special context required. Although I don't handle user support for Python packages, if I did, that would be my go-to approach.