On November 9, 2015 at 7:01:57 AM, Paul Moore (p.f.mo...@gmail.com) wrote:
>  
> This is pretty much why I said earlier that this isn't really a pip
> issue. It applies just as much to Django, to pydoc, etc.
>  
> I'm concerned that what is happening at the moment is that every
> project implements its own workaround for the issues with wrapper
> commands and PATH. Either that or most projects simply ignore the
> issue (after all, 99% of projects aren't installed and used in quite
> as many of a user's Python installations as pip is).

I don’t think every project is going to implement it’s own work around because 
I don’t think the problems even affect most projects. For instance, the 
``django-admin`` command isn’t (typically) going to matter which particular 
Python is invoking it. For most people the only time they ever invoke 
``django-admin`` is when they are creating a new project which the particular 
version of Python you’re using to invoke Django doesn’t really matter for that. 
Beyond that they tend to use ./manage.py which has a shebang at that top that 
they can use to adjust which version of Python is being used.

You also have things like tox, twine, virtualenv, invoke, pypi-cli, supervisor, 
vanity, awscli, Carbon/Graphite, etc which are written in Python but the fact 
that they are is basically an implementation detail and what version of Python 
is executing them simply doesn’t matter at all.

I believe that the vast majority of cases where a Python project comes with a 
CLI, the particular version of Python that is being used to *invoke* that CLI 
is typically unimportant, or if it is important is only important in edge 
cases. This makes it obviously the right thing to just use ``mycoolcli`` as the 
standard command, and maybe have a ``python -m mycoolcli`` for the weird edge 
cases.

Projects like pip (and yes IPython too) care a lot about what version of Python 
is invoking them (or more specifically what version of Python they are 
targeting, which is currently controlled by inspecting sys.executable). I 
believe that these projects are the odd ones out because I’m having a problem 
even naming many of them at all and of the ones I can think of they are mostly 
aimed at Python developers vs being something that even people who don’t care 
about Python at all might be using.

The other thing that’s different about pip is just the fact that it’s a project 
that is basically installed into every single Python environment and will be 
used to “target” every single one of those Python environments. I think it’s 
very unusual for someone to have a Python environment where they aren’t using 
pip to install at least something into that environment.

The default now is to install pip into every environment (virtual or real) 
which means that a lot of people will have a great many number of pips 
installed into a variety of environments. Someone who uses Django a lot might 
also have Django installed a lot into many environments, but a primary 
difference there is Django is going to (typically) be something that is 
foremost in that person’s mind about what version they are going to be using. 
However pip is an incidental thing, people don’t typically think about what 
version of pip they have, they just sort of use whatever is there.

-----------------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA


_______________________________________________
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Reply via email to