On 2 May 2016 at 19:25, Thomas Güttler <guettliml@thomas-guettler.de> wrote:
>
>
> Am 02.05.2016 um 09:14 schrieb Noah Kantrowitz:
>>
>> The correct way to do that these days is `pip install -e .` AFAIK.
>> Setuptools should be considered an implementation detail of installs at
>> best, not really used directly anymore (though entry points are still used
>> by some projects, so this isn't really a strict dichotomy).
>
>
> You say it is an "implementation detail". That's ok, I am user, and I don't
> want to know everything.
>
> There are two ways to handle the implementation detail. I ask myself: why?
>
> If I use `pip install -e mylib` and mylib uses installs_requires=[...] in
> its setup.py, what happens?
>
> I guess there will be two ways the packages get installed on my system. Is
> my assumption correct?

Sort of - pip knows how to read setuptools produced installation
metadata, so even if something is installed via easy_install
(explicitly or implicitly), command like pip list and pip freeze will
still tell report it accurately. That's how tools like pip-compile are
able to work: https://github.com/nvie/pip-tools#readme

The initial run of "pip-compile" may need to fallback to easy_install
in some cases, but the subsequent use of the generated complete
requirements file should always install everything with pip (the exact
versions are pinned, so new dependencies can't be introduced without
another pip-compile run).

> Is this current behaviour intentional?

Not really, it's mainly a matter of it being a lot of work to migrate
implicit installation in setuptools away from easy_install (without
breaking anything), and there being cases where
setuptools/easy_install encourage practices that we genuinely want
people to migrate away from doing (not because they don't work when
you know what you're doing, but because they tend to require
near-encyclopaedic knowledge of Python's import system to debug when
they don't behave as you expect). (Some of those aspects are already
covered in https://packaging.python.org/en/latest/additional/ and
https://github.com/pypa/python-packaging-user-guide/pull/159/files
covers a couple more)

Folks getting their Python runtime from a commercial redistributor can
potentially help by filing tickets with their supplier and generally
agitating for them to increase their level of upstream investment in
shared community infrastructure, but it's currently tough for
community contributors to help move things forward (since the biggest
problems involve interactions between the import system, CPython
interpreter initialisation, setuptools/easy_install, pip, virtualenv,
project setup.py files, and sometimes even the Python Package Index,
and the folks that already have all those moving pieces in their heads
unfortunately tend to have a lot of competing priorities)

Cheers,
Nick.

--
Nick Coghlan   |   ncoghlan@gmail.com   |   Brisbane, Australia
_______________________________________________
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig