-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hanno Schlichting wrote: > Tres Seaver wrote: >> Jens Vagelpohl wrote: >>> On Dec 29, 2007, at 18:28 , Hanno Schlichting wrote: >>>> For the small number of CMF parts I'm +1 for individual eggs. > > I understood both comments as positive votes and have done the dirty > work of moving CMF trunk into separate parts now.
Great, thanks very much! I know from experience how tedious / painful that kind of work is. > I haven't moved the > 2.1 branches yet as it was done for CMFCore. > >>> I like your argument where we could use this as an opportunity to move >>> packages like CMFUid out of the bundle/egg/tarball/whatever that >>> people get when they get the CMF. I wouldn't mind having a division >>> where you have... >>> - CMFCore (the foundation which may be used by itself to develop >>> other kinds of portal software) >>> - CMFDefault + DCWorkflow + (maybe) CMFTopic (a "finished" sample >>> for a CMFCore-based portal software bundle) >>> - CMFUid (optional add-on) >>> - CMFCalendar (optional add-on) >>> - CMFActionIcons (optional add-on) > > I haven't updated the install_requires of the individual eggs yet. But > if you for example "easy_install CMFCalendar" you should get a working > system including its depdendencies which probably includes the rest of > CMF as well. The same goes for the other options, so installing > CMFDefault will pull in DCWorkflow and CMFTopic will probably include > both CMFDefault and DCWorkflow. Careful dependency analysis is needed > here, though. I know of several kinds of dependencies: - Non-conditional imports of the target product in "mainline" code. These must be represented in 'install_requires' code. - Conditional imports in mainline code. I'm not quite sure how to deal with these, but am template to treat them the same for now as the "harder" imports. - Imports which occur only in test code. These should be captured in 'tests_require'. - Implicit imports in ZCML (via dotted names). For now, we should capture thses as 'install_requires'. In the long term, I am tempted to make them part of an "extra" (yes, I know Jim hates them, but the only other choice is to multiply packages). E.g.: extras_require={'zcml': [....]} - Implicit imports in GS profile code. I think these have to be extras, as well. Again, the other choice would be to move the profiles out into separate eggs (which might be cleaner). - >> If we go ahead and break each product out into its own egg, we can >> create one or more "meta eggs" which stitch them back together. E.g., >> the meta egg could have: >> >> install_requires=['Products.GenericSetup', >> 'Products.CMFCore' >> 'Products.CMFDefault', >> 'Products.CMFTopic', >> 'Products.DWorkflow', >> ], >> extras_require={'uid': ['Products.CMFUid'], >> 'calendar': ['Products.CMFCalendar'], >> 'actionicons': ['Products.CMFActionIcons'], >> 'kitchensink': ['Products.CMFUid', >> 'Products.CMFCalendar', >> 'Products.CMFActionIcons', >> ], >> } > > Sounds good - except for the kitchensink name ;) Heh. That is a "give them something to change" gambit pawn. ;) Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHeBV9+gerLs4ltQ4RAuIMAKDcR1i9nZXWPjGZ9cWxDyJL992xowCcDH8s V0eIWbZEA5cpX0MofvP9ouY= =XcKL -----END PGP SIGNATURE----- _______________________________________________ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests