tseaver at palladion
Dec 30, 2007, 2:02 PM
Post #2 of 3
(832 views)
Permalink
|
|
Re: Eggified CMF - was Re: CMF 2.1.1 release
[In reply to]
|
|
-----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 tseaver [at] palladion
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 [at] lists
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests
|
