#2066 closed defect (fixed)

setup.py performs work without a command being specified

Reported by: daira Owned by:
Priority: normal Milestone: 1.11.0
Component: packaging Version: 1.10.0
Keywords: setuptools usability error nevow Cc:
Launchpad Bug:

Description

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$

Change History (13)

comment:1 Changed at 2013-08-28T19:24:13Z by daira

  • Keywords error added

comment:2 Changed at 2013-08-28T19:27:16Z by 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.

comment:3 Changed at 2013-08-29T00:31:33Z by 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!)

Last edited at 2013-08-29T00:33:11Z by daira (previous) (diff)

comment:4 Changed at 2013-08-29T00:32:30Z by daira

  • Keywords nevow added

comment:5 Changed at 2013-09-18T01:49:07Z by daira

  • Summary changed from setup.py does work without a command being specified to setup.py performs work without a command being specified

comment:6 Changed at 2014-06-30T21:54:07Z by zooko

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

comment:7 Changed at 2014-07-02T03:57:00Z by 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

comment:8 follow-up: Changed at 2015-01-15T00:43:40Z by 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 (#2249), 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 (or possibly https://twistedmatrix.com/trac/ticket/7477, but that would introduce a whole 'nother set of problems unless cffi's build process is also improved).

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.

Version 5, edited at 2015-01-15T00:49:47Z by daira (previous) (next) (diff)

comment:9 Changed at 2015-04-12T22:14:20Z by daira

  • Milestone changed from undecided to 1.11.0

comment:10 Changed at 2015-07-21T19:05:29Z by zooko

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

comment:11 in reply to: ↑ 8 Changed at 2015-07-21T20:01:34Z by 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.

comment:12 Changed at 2016-03-22T05:02:52Z by warner

  • Milestone changed from 1.11.0 to 1.12.0

Milestone renamed

comment:13 Changed at 2016-03-26T23:06:32Z by warner

  • Milestone changed from 1.12.0 to 1.11.0
  • Resolution set to fixed
  • Status changed from new to closed

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

Note: See TracTickets for help on using tickets.