Re: [Python-ideas] Looking for input to help with the pip situation
General summary so far ####################### This debate has been very civil so far and quite productive, so thanks to everyone involved. Several issues and solution proposals have been mentioned, so I will make a summary here. Issue 1: running Python is a different command different OS when several versions are installed ================================================================================================== Proposal A: ----------- Suffix Python executable on Windows like on Unix, so that people will type pythonX.X if they want a specify version. Pros: easy and discoverable. Cons: you need a lot of stuff in the system path. Proposal B: ------------ Provide the "py" command on Unix, so that people will type "py -x.x" Pros: no more issues with system path. Just add this command, and register python installations to be listed by "py". Cons: very few people know about "py", even on windows. This would need lots of communication. Harder to change Mac and majors Linux distros setup than just the next windows installer. Issue 2: there is no one and only one obvious way to do venv / pip =================================================================== Because pip and venv are tied to a Python version, there are numerous ways to call them. Just for pip, you have "pip", "py -x.x -m pip", "pythonx.x -m pip" and "pipx". Proposal A: ----------- Decide on one form, and promote it everywhere. Pros: simple. Cons: long and tedious process, with a huge inertia before all 3rd party to it. Would need a "PEP 8 for Python command". Requires "issue 1" to be solved before. Proposal B: ------------ Provide a pipenv-like behavior pipenv is a tool created by the author of "requests" that automatically "do the right thing" by default. The first time you install a package, it creates a virtualenv for the current directory (but don't store it in the current directory). It will then install all packages in there. "pipenv shell" starts a shell in the virtualenv. Dependencies are automatically dumped in a requirement files separating dev and prod. Pros: bypass the multiple installers issue by prompting you what version you wish the first time it creates a virtualenv. Solve the problem of admin rights and system path. Cons: lots of work. Either a new tool or breaking compat with pip. If debian didn't install pip by default, this may not help. Issue 3: pip and virtualenv are not available everywhere =================================================================== Proposal A: ------------ Make a mock "pip" commands for when it's not installed. venv already does that in some cases (see attachements), alhought it does give you the wrong command so it should be fixed. The gist of it: if the users try to run pip install while it's missing, it prints a warning explaining it's not installed and the command you can run to solve the problem plus a link to more information in the documentation. Pros: low friction to implement. Cons: requires to put up a hook somewhere so that each linux distro can input "the proper commands to use" for their system when they package python. More a workaround than a solution. Proposal B: ------------ Make pip and venv part of the standard and request debian that they provide it. Pros: straight forward. Cons: holy war in the making. ................. Can I have +1 and -1 from each of you on each point ? Should I start a new thread for each of them ? Favorite personnal combination ================================ 1 - So far, I like "providing py on unix" better, but I think it's too hard to do. So provide suffix on windows seems more achievable. So +1 for having pythonX.X on windows. 2 - Decide on one form, and promote it everywhere is again the simplest IMO. I love pipenv but the strings to pull to get something like this means it probably would not happen. If we stick to suffix for issue 1, this mean we can promote: pythonX.X -m pip pythonX.X -m venv Everywhere. In the docs. In the tutorials. In teaching classes. This will help a lot to remove all confusions and make the Python start up experience way easier. 3 - getting angry debian devs is probably not wise. The "mock" pip/venv command also plays very well with the 2 other solutions. It means we can promote everywhere: pythonX.X -m cmd It will work most of the time. And when it doesn't, give clear contextual steps on
participants (5)
-
Chris Angelico
-
Michel Desmoulin
-
Nick Coghlan
-
Stephan Houben
-
Todd