2009/3/5 Gary Poster <gary.pos...@gmail.com>: > > On Mar 5, 2009, at 1:43 PM, Martijn Faassen wrote: > >> Hi there, >> >> I know opinions are divergent about 'extra' dependencies in setup.py. >> These ar dependencies that effectively make a single project with a >> single dependency structure into a number of "virtual" packages that >> each can have a separate list of dependencies. Such a virtual package >> that we're currently getting rid of is zope.component[zcml]. > > ... > >> Opinions? > > I disagree with the blanket statement. > > I do lean towards not having the extras for the test package only. > I'm fine with the policy "If you want zope.testing for your tests, > then keep it as a dependency for the package". > > But I like to have the option of extras for testing additional setups. > > zc.async uses extras so that the main tests show the functionality as > a Python library; another level adds more Zope dependencies, with > associated tests; and the last level adds the most. I could have > divided these up into multiple teensy-weensy packages but I didn't > really want to. It seemed like overkill. > > I've also done this in other circumstances in which code could use > zope.proxy/zope.security, but I really didn't want to add the hard > dependency. The tests to show that proxies were handled correctly > were only part of the "extras". Dividing this package also would have > made no sense--it was already just a few small classes. > > For a package as central as zope.component, I think the pattern Tres > is pursuing--dividing everything up--makes sense. > > For most other packages, I personally feel that there are > circumstances in which extras are a useful tool.
A strong +1 on that explanation. -- WBR, Dan Korostelev _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )