[Framework-Team] package syndication: practical problems + possible solution

Tue Apr 8 18:45:59 UTC 2014

thanks Jens, for the comments. I didn't want to start this discussion on
plone-dev. the topic is old, many arguments already stated. and i didn't
want to start a flame, which stops development on this PLIP. i just
wanted to re-think it again and hear your opinion.

the missing controlpanel shouldn't be a problem for plone.app.event,
actually, as long as there are registry entries.

and timo, i didn't mean to merge plone.app.event, .contenttypes or the
like. of course they should stay separate.

see you later, johannes

On Tue, 2014-04-08 at 16:58 +0200, Jens W. Klein wrote:
> Hi FWT,
> 
> Johannes asked me to comment on this. Usally I'd prefer this on the 
> developers list, but I dont x-post anyway. Feel free to move it over.
> 
> On 2014-04-07 23:15, Johannes Raggam wrote:
> > Hey FWT,
> >
> > I want to share a problematic experience with the Python-package
> > syndication effort, the https://dev.plone.org/ticket/13283 PLIP.
> 
> Base idea is good, but imo it does not solve the core problems.
> 
> > At wine/beer sprint we moved plone.app.event's timezone vocabs to
> > plone.app.vocabulary, because we found that generally useful and worth
> > to be used elsewhere.
> 
> This makes sense i.e. to stick the correct timezones to the effective date.
> 
> > Then we moved plone.app.event's controlpanel to P.CMFPlone,  because it
> > just does datetime related settings, not necessarily specific to the
> > calendaring framework plone.app.event.
> >
> > Now, the current refactored plone.app.event 2.0 branch, which somehow
> > depends on newest p.a.vocabularies and P.CMFPlone, cannot easily be used
> > in Plone < 5, just because of the dependency on CMFPlone.
> 
> Changes in p.a.vocabularies we're made carefully and are tested in Plone 
> 4.3 and Plone 5 coredev buildouts. So this package can be used in both 
> worlds. The ``plone.app.vocabularies.AvailableTimezones`` vocabulary 
> finds both the old p.a.event controlpanel settings and the new ones for 
> which i created a pull request here 
> https://github.com/plone/Products.CMFPlone/pull/203
> If theres no p.a.event installed in 4.3 the vocabulary wont be 
> registered at all (because of a zcml:condition).
> 
> > With the package syndication effort, we might give up some inter-version
> > compatibility of selected packages like plone.app.event, and others,
> > just because other dependencies like p.a.controlpanels cannot be
> > released independently from CMFPlone anymore.
> 
> This is true, but otoh we have at the moment way too many packages. I 
> must admit I did not much work on the core in the last years, esp. in 
> the 4-series.
> 
> At wine and beer sprint I was a bit shocked about how many packages we 
> have and how many dependencies are there. Even for small changes one 
> have to touch often three packages.
> 
> If there would be a exact dividing rule and clean dependency chain 
> between packages this would make sense. But at the moment it feels more 
> like an uncontrolled package mesh than a directed graph. Would be funny 
> to visualize that.
> 
> > SOLUTION (?)
> >
> > That would actually be different, if we don't do these refactorings like
> > the controlpanel one, but merge the package namespaces into another
> > umbrella namespace, just called "plone.app", and refactor the packages
> > to not have any code in it's __init__.py, which is a requirement for
> > these namespace packages to work. That would also be less work, than
> > refactoring everything into CMFPlone. Also, for backwards compatibility,
> > individual packages/namespaces can still be released independently.
>  >
>  > Makes sense?
> 
> Is this the solution here? I dont think so. Just changing how we deal 
> with namespaces wont help.
> 
> I think the solution is moreover to move the stuff to the place it 
> belongs too. plone.app.controlpanel is a good example here: It can be 
> moved entirely to Products.CMFPlone.controlpanel and all is fine.
> 
> There are more difficult cases like the code around dexterity and plone 
> base content handling:
> 
> - plone.dexterity, plone.app.dexterity, plone.supermodel, 
> plone.app.*field, plone.app.*behavior plone.app.fieldsets, ...
> 
> - plone.content, plone.app.content, plone.folder, plone.app.folder, ...
> 
> Do we need them all? Do we really need want to have division line 
> between content and folder, basic stuff and plone specific? So who plans 
> i.e. to use plone.folder not in plone? (I'd say nobody) It makes things 
> difficult to understand, difficult to find in code, difficult to 
> document and difficult to maintain. Two packages would imo be enough: 
> One for the dexterity stuff inlcuding supermodel and one for all base 
> type framework things. Any, just my 0.02 €. We need to think about this 
> carefully, but it would save time in future we could invest to solve 
> other problems.
> 
> Other ideas:
> - move plone.app.vocabularies entirely to 
> Products.CMFPlone.vocabularies. since these are named utilities there 
> would be almost zero impact on other packages.
> 
> - merge z3c.caching, plone.caching, plone.app.caching and 
> plone.cachepurging
> 
> - merge plone.portlets, plone.app.portlets, plone.app.layout.portlets
> 
> - merge plone.app.viewletmanager, plone.app.layout.viewlets, ...
> 
> - Cleanup the monkey-patchy swamp around Products.PlonePAS: get rid of 
> Products.PlonePAS and put the monkey patches in place where they belong 
> to: Products.PluggableAuthService and the additional features in 
> Products.CMFPlone. PlonePAS was made at a time where PAS was new and 
> optional. I think we wont ever go back to the default userfolder.
> 
> Downside: all the current namespaces are in heavy use. We would b
> reak to mcuh or would have a whole bunch of BBB code/ imports around. 
> But we would have a big cleanup.
> 
> regards Jens

-- 
programmatic  web development
di(fh) johannes raggam / thet
python plone zope development
plone framework  team  member
mail: office at programmatic.pro
web:  http://programmatic.pro
      http://bluedynamics.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.plone.org/pipermail/plone-framework-team/attachments/20140408/0d6cacce/attachment.asc>