Two ways to download python packages - I prefer one
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? Do wheels help here? Or is there a way to use npm for python packages? Regards, Thomas Güttler -- Thomas Guettler http://www.thomas-guettler.de/
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, 2016, at 12:03 AM, Thomas Güttler <guettliml@thomas-guettler.de> wrote:
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?
Do wheels help here?
Or is there a way to use npm for python packages?
Regards, Thomas Güttler
-- Thomas Guettler http://www.thomas-guettler.de/ _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
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 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, 2016, at 12:03 AM, Thomas Güttler <guettliml@thomas-guettler.de> wrote:
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?
Do wheels help here?
Or is there a way to use npm for python packages?
Regards, Thomas Güttler
-- Thomas Guettler http://www.thomas-guettler.de/ _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
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. Console scripts et. al. are still build/install system dependent. On 5/2/2016 03:16, Alex Grönholm wrote:
You make it sound like there's a plausible alternative to setuptools entry points -- is there?
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? Is this current behaviour intentional? Regards, Thomas Güttler -- Thomas Guettler http://www.thomas-guettler.de/
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
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
participants (6)
-
Alex Grönholm -
Alexander Walters -
Daniel Holth -
Nick Coghlan -
Noah Kantrowitz -
Thomas Güttler