On 7 November 2017 at 03:52, Michel Desmoulin email@example.com wrote:
Le 06/11/2017 à 09:47, Nick Coghlan a écrit :
On 6 November 2017 at 16:47, Michel Desmoulin firstname.lastname@example.org wrote:
I really want some people from this list to discuss here so we can find a way to either unify a bit the way we install and use pip, or find a way to express a tutorial that always works for people on the most popular platforms and spread the word so that any doc uses it.
https://docs.python.org/3/installing/#basic-usage is as close as we've been able to get to that for the time being.
I know and you still:
- have to use py -m on windows, python3 linux, python in virtualenv...
Which is why we advise getting into a virtual environment ASAP, such that the only platform specific thing folks necessarily need to learn to get started is how to get to that first working virtual environment.
- install pip manually on linux
Other distros (like Fedora) provide pip by default.
- make sure the system path is correctly set
Recent python.org Windows installers do this automatically, but there are unfortunately still lots of ways for things to go wrong.
Stuff that they will forget on the next install, or miss when changing plateform.
Yes, because computers are awful, and incredibly user hostile. We don't have a magic wand to wave to fix that.
And assume that stuff in any tutorial you make they know this stuff.
This is a strong barrier or entry IMO.
Sure, but it's not one we can readily fix - the user hostility of command line environments and the compromises we have to make to abide by platform conventions are in the hands of operating system vendors, and there's only so much we can do to paper over those distinctions when user lock-in and putting barriers in the way of cross-device portability is a core part of commercial OS vendors' business models.
This is a big part of why mobile client devices with cloud backends are so popular, even for development purposes: they allow for a much simpler developer experience that avoids decades of accumulated cruft in the desktop operating system command line experience. Even there though, you're faced with the fact that once you choose a provider, whatever you do there will probably be locked into that provider and not transferable elsewhere.