Are any base plone packages used in Zope/CMF projects?

Zope
1

In Plone we have several "twin" packages. You have a base plone.example and you have plone.app.example. Theoretically, plone.example is often intended to be usable in plain Zope or CMF as well, where plone.app.example would have Plone-specific code that builds on the base package.

In the Plone community we often wonder: is anyone actually using any of these base packages outside of Plone? In discussions, the main feeling is that it was a nice idea to have two packages, but that probably no one is actually using the base one outside of Plone. In that is true, we might as well merge those twin packages, and lighten some of our maintenance burden. I guess in most cases we would merge the base plone.example package into plone.app.example. plone.example would be left unmaintained.

So: is anyone using these in their Zope or CMF projects? If so, please speak up.

I count ten package couples:

  • plone.contentrules (readme: 'provides a "pure Zope" implementation of a a rules engine which allows arbitrary conditions and actions to be combined into rules, and rules to be executed dependent on events.') and plone.app.contentrules with Plone-specific rules. See a comment by me in a discussion about merging these two.
  • plone.portlets (readme: "generic infrastructure for managing portlets") and plone.app.portlets with some actual portlets specific to Plone.
  • plone.caching (readme: "framework for the management of cache headers") and plone.app.caching (next to z3c.caching actually)
  • plone.dexterity (readme: "Dexterity is a system for building content types, both through-the-web and as filesystem code. It is aimed at Plone, although this package should work with plain Zope + CMF systems.") and plone.app.dexterity
  • plone.event (readme: "Event/Calendaring related infrastructure. Recurrence calculation tools based on RFC2445 and timedelta recurrence rules, timezone tools and date conversion tools.") and plone.app.event. I did not even know that plone.event existed...
  • plone.i18n (readme: "Advanced i18n/l10n features useful in a CMS environment.") and plone.app.i18n
  • plone.registry (readme: "This package provides debconf-like (or about:config-like) settings registries for Zope applications. A registry, with a dict-like API, is used to get and set values stored in records.") and plone.app.registry
  • plone.testing (readme: "Testing infrastructure for Zope and Plone projects.") and plone.app.testing
  • plone.uuid (readme: "This is a minimal package that can be used to obtain a universally unique identifier (UUID) for an object.") and plone.app.uuid
  • plone.z3cform (readme: this "is a library that enables the use of z3c.formin Zope. It depends only on Zope and z3c.form.") and plone.app.z3cform

I have asked the same question in the zopefoundation/meta repo.

1 Like
2

I suspect trying to merge them together will create circular dependency problems.

There are also some persistent classes that would need module aliases forever.

And it also sounds like adding a short-term maintenance burden in order to avoid a minimal long-term one. (The base packages don't tend to have many changes or require updates when there is a new version of Plone, because they've been designed to not depend on much of the rest of Plone.)

tl;dr I'm not sure it's worth the effort.

1 Like
3

Possibly only hypothetical concern: of the items on the list above plone.uuid and plone.testing are 3-clause BSD licensed, not GPLv2.

Otherwise, for these two packages:

  • plone.uuid is probably limited in practical scope to use just inside Plone (although the pattern of adapter-to-UUID via IUUID is hypothetically of utility in any ZCA application that needs to use UUIDs, so I am unsure).

  • plone.testing layers could be (and might be to someone) of practical useful for any ZCA/ZODB/Zope2 application.

4

I would be a +1 for reducing the number of packages in core Plone, but as David pointed out, this could not be an easy task.

One of my additional concerns is related to packages that list one of the "obsolete" packages as a dependency, which could trigger installation problems for future Plone users.

5

Reducing the amount of packages to maintain has its appealing, but the implications of moving the code, etc might, as @davisagli mentions, might not bring too much benefits...

If the maintenance effort is high, we can try to reduce it by automating more parts of it. plone.meta is already providing a few helping hands, but if we look at zope.meta there is plenty more that we can automate (bump/drop python versions, update trove classifiers..)

1 Like
6

Instead of moving namespaces we can join them in one package, like

.
└── src
    └── plone
        ├── app
        │   └── contentrules
        └── contentrules
  • The release name can be one of both (I would go for the shorter name).
  • actually I once managed to join the git history, so it would not get lost under src for both repos.
  • tests would still reside under both folders (unless we decide to move them to /test - different discussion) and could be started separately.
  • import would not break
  • easy to achieve.
2 Likes
7

That might work.

8

How would that work? Something like this:?

  • The setup.py would have name="plone.contentrules".
  • Its distribution would have all code that is currently divided over two packages.
  • We would still have a separate plone.app.contentrules package, but this would contain no code, and only have a dependency on plone.contentrules, so nothing breaks if projects have declared a dependency on plone.app.contentrules. This would be similar to the Zope2 package which currently is basically empty, apart from an install_requires=["Zope>=4.0"] to get the new name of the package.

That could work. And it could also work for merging plone.(app).portlets and plone.portlet.collection/static.

1 Like
9

+1 for keeping plone.testing an individual package. It can (and is) perfectly used in pure Zope projects which do not want to install a whole Plone stack just to use its layers.

3 Likes
10

Excact. Execpt this thing with setup.py is a bit old school, pyproject.toml it is these days (empty setup() call fixes it for legacy usages).

1 Like