[Zope-CMF] Re: Eggified CMF - was Re: CMF 2.1.1 release

[Tres Seaver]

-----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.com
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-----