On 7 November 2017 at 03:52, Michel Desmoulin <desmoulinmic...@gmail.com> wrote:
>
>
> Le 06/11/2017 à 09:47, Nick Coghlan a écrit :
>> On 6 November 2017 at 16:47, Michel Desmoulin <desmoulinmic...@gmail.com> 
>> 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

s/Linux/Ubuntu/

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.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to