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 <[email protected]> wrote: > On 2 May 2016 at 19:25, Thomas Güttler <[email protected]> > 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 | [email protected] | Brisbane, Australia > _______________________________________________ > Distutils-SIG maillist - [email protected] > https://mail.python.org/mailman/listinfo/distutils-sig >
_______________________________________________ Distutils-SIG maillist - [email protected] https://mail.python.org/mailman/listinfo/distutils-sig
