Non-hack way of detecting pip from setup.py

[anatoly techtonik]

https://stackoverflow.com/questions/9959279/detect-pip-in-setup-py

What is the official way to detect running pip?

It is needed for `--single-version-externally-managed` option.

[Daniel Holth]

Would this error message need to be any different than if you tried to
run "python setup.py install" on the same package?

[anatoly techtonik]

It is not me who is having the issue. How can I detect that this feature is present without pip?

[Bill Deegan]

The issue was that when the  package (scons-2.3.0 or any version on pypi) was installed, pip seems to be calling setup.py with the --single-version-externally-managed flag which doesn't exist in distutils and failing.

(you can try via "pip install scons")

The suggested fix I found on stackoverflow (I think) was to detect that it was being run by pip and then to import setuputils instead.

Is it expected that pip would be calling setup.py with the --single-version-externally-managed flag?

Or I guess the real question, is what's the "correct" way to resolve this issue.

Thanks!

-Bill 

[Daniel Holth]

pip always runs setup.py under setuptools. It does not matter whether
setup.py imports it or not.

scons has a complicated setup.py that does not work well with pip. It
is not designed to be installed into a virtualenv.

[William Deegan]

Daniel,

Sure.
I'm working on making it work under virtualenv.

I think a lot of the complexity in the current setup.py is unwarranted and could be simplified and made to work under virtualenv.

-Bill

[Carl Meyer]

Hi Bill,

On 03/06/2014 03:00 PM, Bill Deegan wrote:
> The issue was that when the package (scons-2.3.0 or any version on
> pypi) was installed, pip seems to be calling setup.py with
> the --single-version-externally-managed flag which doesn't exist in
> distutils and failing.
> (you can try via "pip install scons")
>
> The suggested fix I found on stackoverflow (I think) was to detect that
> it was being run by pip and then to import setuputils instead.

In general, this is not necessary.

> Is it expected that pip would be calling setup.py with the
> --single-version-externally-managed flag?

Yes.

> Or I guess the real question, is what's the "correct" way to resolve
> this issue.

I haven't tested this, but I would guess that if you use "cmdclass" to
override the "install" command class (as scons' setup.py does), you need
to make your version of "install" a subclass of setuptools' version, not
distutils', otherwise it won't work with pip. I suppose if you really
want to, you could do this conditionally only if you find
"--single-version-externally-managed" in sys.argv, but if possible I'd
say you should either a) eliminate your custom install cmdclass, or b)
just always build on setuptools rather than distutils.

When it is imported, setuptools monkeypatches distutils to replace some
of distutils' default command classes with its own. Pip executes
setup.py in a special way that forces an import of setuptools (and thus
executes setuptools' monkeypatch), even for projects whose setup.py uses
only distutils. This allows pip to treat all setup.py's the same, and
assume they all support setuptools features. But by supplying your own
custom cmdclass for install that inherits from distutils, you prevent
this monkeypatch from taking effect.

Carl