Hello all, I wonder what the status of easy_install is. I keep finding people who needed to install something 'path.py' is the latest, who needed to use pip, and couldn't get easy_install to work. Should we tell people that easy_install is deprecated, or ask them to file bugs when they could not get it to work, or ... Laura
On Tue Feb 24 2015 at 10:54:14 AM Laura Creighton <lac@openend.se> wrote:
Hello all, I wonder what the status of easy_install is. I keep finding people who needed to install something 'path.py' is the latest, who needed to use pip, and couldn't get easy_install to work. Should we tell people that easy_install is deprecated, or ask them to file bugs when they could not get it to work, or ...
Tell people to use pip. Having ensurepip in Python 2.7 and 3.4 makes it as official as anything will be as the recommended tool to install projects. Otherwise easy_install has nothing to do directly with python-dev so I don't think we can comment on a group as to what people should do in terms of bugs, etc.
On 24 February 2015 at 16:30, Brett Cannon <brett@python.org> wrote:
Tell people to use pip. Having ensurepip in Python 2.7 and 3.4 makes it as official as anything will be as the recommended tool to install projects. Otherwise easy_install has nothing to do directly with python-dev so I don't think we can comment on a group as to what people should do in terms of bugs, etc.
Bug reports would go to the setuptools project, but I agree, "use pip" is a better suggestion. And if pip won't work, it would be good to know why. Paul
On 02/24/2015 08:44 AM, Paul Moore wrote:
On 24 February 2015 at 16:30, Brett Cannon wrote:
Tell people to use pip. Having ensurepip in Python 2.7 and 3.4 makes it as official as anything will be as the recommended tool to install projects. Otherwise easy_install has nothing to do directly with python-dev so I don't think we can comment on a group as to what people should do in terms of bugs, etc.
Bug reports would go to the setuptools project, but I agree, "use pip" is a better suggestion. And if pip won't work, it would be good to know why.
And if/when pip doesn't work, a bug may need to be filed the project trying to be installed. -- ~Ethan~
On Tue, Feb 24, 2015 at 11:44 AM, Paul Moore <p.f.moore@gmail.com> wrote:
And if pip won't work, it would be good to know why.
Is there a recommended way to invoke pip from setup.py? When I specify "tests_require=" and run "python setup.py test", the requirements get installed using setuptools' easy_install function.
On Tue, Feb 24, 2015 at 1:31 PM, Alexander Belopolsky <alexander.belopolsky@gmail.com> wrote:
On Tue, Feb 24, 2015 at 11:44 AM, Paul Moore <p.f.moore@gmail.com> wrote:
And if pip won't work, it would be good to know why.
Is there a recommended way to invoke pip from setup.py? When I specify "tests_require=" and run "python setup.py test", the requirements get installed using setuptools' easy_install function.
The solution is to not do that. A substitute is to specify your test requirements in a [test] extra and install them with pip or to run tests with tox. This gives control of the installer back to the user instead of the setup.py author. https://pythonhosted.org/setuptools/setuptools.html#declaring-extras-optiona... own-dependencies
On Tue, Feb 24, 2015 at 2:03 PM, Daniel Holth <dholth@gmail.com> wrote:
Is there a recommended way to invoke pip from setup.py? When I specify "tests_require=" and run "python setup.py test", the requirements get installed using setuptools' easy_install function.
The solution is to not do that. A substitute is to specify your test requirements in a [test] extra and install them with pip or to run tests with tox. This gives control of the installer back to the user instead of the setup.py author.
Isn't this a chicken and egg problem? I currently have tests_require=['tox'], and this is exactly what tox recommends: https://testrun.org/tox/latest/example/basic.html#integration-with-setuptool... Note that my CI box is a CentOS 6.5 with Python 2.6.6, setuptools 0.6. This is still a very common server configuration. What is the recommended way to bootstrap tox in such environment?
That might mostly do what you want, since tox could install any additional test requirements based on its configuration. On Tue, Feb 24, 2015 at 4:21 PM, Alexander Belopolsky <alexander.belopolsky@gmail.com> wrote:
On Tue, Feb 24, 2015 at 2:03 PM, Daniel Holth <dholth@gmail.com> wrote:
Is there a recommended way to invoke pip from setup.py? When I specify "tests_require=" and run "python setup.py test", the requirements get installed using setuptools' easy_install function.
The solution is to not do that. A substitute is to specify your test requirements in a [test] extra and install them with pip or to run tests with tox. This gives control of the installer back to the user instead of the setup.py author.
Isn't this a chicken and egg problem? I currently have
tests_require=['tox'],
and this is exactly what tox recommends:
https://testrun.org/tox/latest/example/basic.html#integration-with-setuptool...
Note that my CI box is a CentOS 6.5 with Python 2.6.6, setuptools 0.6. This is still a very common server configuration. What is the recommended way to bootstrap tox in such environment?
On Tue, Feb 24, 2015 at 4:24 PM, Daniel Holth <dholth@gmail.com> wrote:
That might mostly do what you want, since tox could install any additional test requirements based on its configuration.
Does "that" refer to using tests_require=['tox'] as I described below? This means using easy_install implicitly and being exposed to easy_install bugs. Note that my attempts to avoid easy_install so far led to dependency hell starting from the need to install virtualenv. Unlike setuptools, pip does not seem to be able to install dependencies in a temporary directory. It wants a full-blown venv tree.
On Tue, Feb 24, 2015 at 4:21 PM, Alexander Belopolsky <alexander.belopolsky@gmail.com> wrote:
On Tue, Feb 24, 2015 at 2:03 PM, Daniel Holth <dholth@gmail.com> wrote:
Is there a recommended way to invoke pip from setup.py? When I
specify
"tests_require=" and run "python setup.py test", the requirements get installed using setuptools' easy_install function.
The solution is to not do that. A substitute is to specify your test requirements in a [test] extra and install them with pip or to run tests with tox. This gives control of the installer back to the user instead of the setup.py author.
Isn't this a chicken and egg problem? I currently have
tests_require=['tox'],
and this is exactly what tox recommends:
https://testrun.org/tox/latest/example/basic.html#integration-with-setuptool...
Note that my CI box is a CentOS 6.5 with Python 2.6.6, setuptools 0.6.
This
is still a very common server configuration. What is the recommended way to bootstrap tox in such environment?
On 25 Feb 2015 07:23, "Alexander Belopolsky" <alexander.belopolsky@gmail.com> wrote:
On Tue, Feb 24, 2015 at 2:03 PM, Daniel Holth <dholth@gmail.com> wrote:
Is there a recommended way to invoke pip from setup.py? When I
specify
"tests_require=" and run "python setup.py test", the requirements get installed using setuptools' easy_install function.
The solution is to not do that. A substitute is to specify your test requirements in a [test] extra and install them with pip or to run tests with tox. This gives control of the installer back to the user instead of the setup.py author.
Isn't this a chicken and egg problem? I currently have
tests_require=['tox'],
and this is exactly what tox recommends:
https://testrun.org/tox/latest/example/basic.html#integration-with-setuptool...
Note that my CI box is a CentOS 6.5 with Python 2.6.6, setuptools 0.6.
This is still a very common server configuration. What is the recommended way to bootstrap tox in such environment? If running in the system Python isn't absolutely essential, then the Python 2.7 collection from softwarecollections.org is the preferred way to get a newer Python 2 (including pip et al) on CentOS. You can also get access to Python 3 that way. Failing that, pip & virtualenv are also available from the EPEL 6 repos. Both of those approaches rely on the system package manager to do the bootstrapping of the Python specific tooling. If both softwarecollections.org and EPEL are considered unacceptable dependencies, then you're going to have to do your own bootstrapping for PyPI access on CentOS (which may include relying on easy_install to bootstrap pip and/or virtualenv) Regards, Nick.
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe:
https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
The other option might be to use http://bitbucket.org/dholth/setup-requires It uses pip to install requirements into an isolated directory before setup.py runs, with pip, doing exactly what you requested. On Feb 24, 2015 5:44 PM, "Nick Coghlan" <ncoghlan@gmail.com> wrote:
On 25 Feb 2015 07:23, "Alexander Belopolsky" < alexander.belopolsky@gmail.com> wrote:
On Tue, Feb 24, 2015 at 2:03 PM, Daniel Holth <dholth@gmail.com> wrote:
Is there a recommended way to invoke pip from setup.py? When I
specify
"tests_require=" and run "python setup.py test", the requirements get installed using setuptools' easy_install function.
The solution is to not do that. A substitute is to specify your test requirements in a [test] extra and install them with pip or to run tests with tox. This gives control of the installer back to the user instead of the setup.py author.
Isn't this a chicken and egg problem? I currently have
tests_require=['tox'],
and this is exactly what tox recommends:
https://testrun.org/tox/latest/example/basic.html#integration-with-setuptool...
Note that my CI box is a CentOS 6.5 with Python 2.6.6, setuptools 0.6.
This is still a very common server configuration. What is the recommended way to bootstrap tox in such environment?
If running in the system Python isn't absolutely essential, then the Python 2.7 collection from softwarecollections.org is the preferred way to get a newer Python 2 (including pip et al) on CentOS. You can also get access to Python 3 that way.
Failing that, pip & virtualenv are also available from the EPEL 6 repos.
Both of those approaches rely on the system package manager to do the bootstrapping of the Python specific tooling.
If both softwarecollections.org and EPEL are considered unacceptable dependencies, then you're going to have to do your own bootstrapping for PyPI access on CentOS (which may include relying on easy_install to bootstrap pip and/or virtualenv)
Regards, Nick.
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe:
https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
participants (7)
-
Alexander Belopolsky -
Brett Cannon -
Daniel Holth -
Ethan Furman -
Laura Creighton -
Nick Coghlan -
Paul Moore