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
On 2 May 2016 at 19:25, Thomas Güttler 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
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
Hypothetically, the alternative is to break non-application entrypoints
(the ones NOT used for console scripts or gui applications) into some
other infrastructure. The people that use entrypoints for their plugin
systems might be given a build system agnostic option if that were the
case.
You make it sound like there's a plausible alternative to setuptools
entry points -- is there?
02.05.2016, 10:14, Noah Kantrowitz kirjoitti:
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
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).
--Noah
> On May 2,
I was told this:
> `python setup.py develop` uses urllib2 to download distributions whereas pip
uses requests
Souce: http://stackoverflow.com/a/36958874/633961
This can create confusing situations and I want to avoid this.
Is there a way to use only **one** way to install python packages?