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
