Entry points are separate from the build and install systems bundled with setuptools. Usually when we talk about replacing or deprecating setuptools we mean first the install part, then the build part. Entry points are fine. The core reason we want to use pip to install (including for development installations) instead of setup.py to install is that "setup.py install" is potentially different for every single version of every package, while "pip install" is consistent. On Mon, May 2, 2016 at 6:19 AM Nick Coghlan <ncoghlan@gmail.com> wrote:
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