setup.py performs work without a command being specified

[daira]

tahoe@i-a419d13f:~/allmydata-tahoe-1.10.0$ python setup.py 
Not found: tahoe-deps
Not found: ../tahoe-deps

Installed /home/tahoe/allmydata-tahoe-1.10.0/Twisted-11.1.0-py2.7-linux-x86_64.egg
Searching for zope.interface==3.6.0,==3.6.1,==3.6.2,>=3.6.5
Reading http://pypi.python.org/simple/zope.interface/
Best match: zope.interface 3.6.1
Downloading https://tahoe-lafs.org/source/tahoe-lafs/deps/tahoe-lafs-dep-eggs/zope.interface-3.6.1-py2.7-linux-x86_64.egg
Processing zope.interface-3.6.1-py2.7-linux-x86_64.egg
creating /home/tahoe/allmydata-tahoe-1.10.0/zope.interface-3.6.1-py2.7-linux-x86_64.egg
Extracting zope.interface-3.6.1-py2.7-linux-x86_64.egg to /home/tahoe/allmydata-tahoe-1.10.0

Installed /home/tahoe/allmydata-tahoe-1.10.0/zope.interface-3.6.1-py2.7-linux-x86_64.egg
usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
   or: setup.py --help [cmd1 cmd2 ...]
   or: setup.py --help-commands
   or: setup.py cmd --help

error: no commands supplied
tahoe@i-a419d13f:~/allmydata-tahoe-1.10.0$

[nejucomo]

The reason it does this work is to work around the Nevow bug documented in #2032. The existence of #2032 shows that this work-around does not fix all packaging use cases.

Removing Nevow as a dependency (#1963) would address both this ticket and #2032, and simplify setup.py complexity, and make more installation use cases work.

[daira]

To be more precise it was to work around #440 and #455 (which were due to the same underlying problem with Nevow importing its dependencies at setup time). Specifically it's caused by this:

setup_requires += [req for req in install_requires if req.startswith('Twisted') or req.startswith('zope.interface')]

So setuptools/zetuptoolz is kinda sort-of behaving correctly (for once) in building zope.interface before attempting the rest of the setup, because that's what we asked it to do. Therefore I think this should probably be wontfixed.

While I agree that removing Nevow as a dependency would be extremely helpful, I don't think it should be a blocker for anything else. In the short term we can unblock things like pip installation etc. just by getting someone to release another version of Nevow (even if it did not have any source changes!)

[zooko]

Removing the setup_requires would also help with comment:13:ticket:2055.

[nejucomo]

While experimenting with #2255 and chatting about packaging at the LAFS summit, we began searching for setup_requires cases, which present a difficult wart when attempting to implement a peep based installation.

We immediately found the line in question Daira's comment 3 above and I realized that the line in question may no longer be necessary *if* we upgrade the Nevow dependency, which may be feasible - see: ticket:2032#comment:18

[daira]

Despite the release of Nevow 0.11.1, the "line in question" (setup.py#L131) still exists. This is because, very annoyingly, Nevow 0.11.1 declared a dependency on Twisted >= 13.0.0 (#2291), which we can't use on Windows because of #2028. This situation is likely to persist until we are able to depend on a version of Twisted that fixes ​https://twistedmatrix.com/trac/ticket/6032.

We *could* use the hack in setup.py#L131 only on Windows. I don't like this solution because it increases the divergence in build behaviour between Windows and other platforms even further.

[zooko]

I think a good next-step on this is #2473 (stop using setup_requires).

[daira]

Replying to daira:

We could use the hack in setup.py#L131 only on Windows.

That is in fact what we do now (since 1.10.1).

I don't like this solution because it increases the divergence in build behaviour between Windows and other platforms even further.

I still don't like it. I think we should use the pypiwin32 wheel instead, but that is blocked on switching to pip (#2077) or newish setuptools (#2044), because wheels cannot be built/installed by zetuptoolz.

[warner]

Milestone renamed

[warner]

We no longer use setup_requires=, so I think we can close this one.