PLIP idea: Create a PloneCore package

[Laurence Rowe]

1. The Plone package currently lists a number of dependencies that are
not installed by default:

* Products.CMFPlacefulWorkflow
* kupu
* plone.app.openid
* plone.app.iterate

There's also the Products.Marshall dependency transitively through
Products.Archetypes. Its ControlledMarshaller is a core dependency of
AT but it also defines a marshaller_tool which may be installed
through the Add/remove products control panel.

It seems likely that we will add more optional dependencies at some
point, plone.app.discussion and plone.app.caching being obvious
contenders.

2. With the new collections implementation, plone.app.collection, it
should become practical to build a site completely without Archetypes.
The only dependency on ATContentTypes/Archetypes in CMFPlone seems to
be the default profile. It would seem sensible to move this over to
ATContentTypes.


For the above reasons I think that the current ``Plone`` package
(containing Products.CMFPlone) should be renamed to ``PloneCore``.
This package can drop the optional dependencies and
ATContentTypes/Archetypes.

A ``Plone`` meta-package can then be created containing no code, but
specifying dependencies on:

* Products.ATContentTypes
* Products.CMFPlacefulWorkflow
* kupu
* plone.app.openid
* plone.app.iterate
* and any other optional packages we deem core to Plone.


Laurence

------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers

[Hanno Schlichting-4]

On Sat, Jul 24, 2010 at 9:29 PM, Laurence Rowe <[hidden email]> wrote:
> 2. With the new collections implementation, plone.app.collection, it
> should become practical to build a site completely without Archetypes.
> The only dependency on ATContentTypes/Archetypes in CMFPlone seems to
> be the default profile.

Oh, no, far from it. The dependency reduction work I did last year
didn't get merged.

There's a ton of circular dependencies all the way around. A simple
one is in PloneTestCase that insists on creating a self.folder Members
folder. The only folder implementation we have comes from
plone.app.folder these days, which depends on Archetypes.

There's dependencies in all likely and unlikely places. Like the
markup control panel depending on Products.Archetypes.mimetype_utils.
Or plone.app.form containing kss support code and plone.app.kss
depending on Archetypes for some helper functions. plone.app.portlets
does a ZCML registrations for ATCTMixin, ... the list goes on and on.
This isn't impossible to solve, I did that once already. It's just a
lot of changes in almost all distributions we have. Doing that work on
dedicated PLIP branches for each distribution is quite a bit of an
overhead.

> For the above reasons I think that the current ``Plone`` package
> (containing Products.CMFPlone) should be renamed to ``PloneCore``.
> This package can drop the optional dependencies and
> ATContentTypes/Archetypes.

I think this is far too early.

I'm all for starting the work on the dependency reduction stuff again,
so this might become feasible at some point. But it's a ton of work -
in the work I did, I still had the testing dependencies on
PloneTestCase, as those where too much work to get rid of. Rewriting
all tests using plone.app.testing and adjusting them to work without
any type of default content or workflow is probably the best way
forward here.

Hanno

------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers

[Laurence Rowe]

On 24 July 2010 21:14, Hanno Schlichting <[hidden email]> wrote:

> On Sat, Jul 24, 2010 at 9:29 PM, Laurence Rowe <[hidden email]> wrote:
>> 2. With the new collections implementation, plone.app.collection, it
>> should become practical to build a site completely without Archetypes.
>> The only dependency on ATContentTypes/Archetypes in CMFPlone seems to
>> be the default profile.
>
> Oh, no, far from it. The dependency reduction work I did last year
> didn't get merged.
>
> There's a ton of circular dependencies all the way around. A simple
> one is in PloneTestCase that insists on creating a self.folder Members
> folder. The only folder implementation we have comes from
> plone.app.folder these days, which depends on Archetypes.
>
> There's dependencies in all likely and unlikely places. Like the
> markup control panel depending on Products.Archetypes.mimetype_utils.
> Or plone.app.form containing kss support code and plone.app.kss
> depending on Archetypes for some helper functions. plone.app.portlets
> does a ZCML registrations for ATCTMixin, ... the list goes on and on.
> This isn't impossible to solve, I did that once already. It's just a
> lot of changes in almost all distributions we have. Doing that work on
> dedicated PLIP branches for each distribution is quite a bit of an
> overhead.
>
>> For the above reasons I think that the current ``Plone`` package
>> (containing Products.CMFPlone) should be renamed to ``PloneCore``.
>> This package can drop the optional dependencies and
>> ATContentTypes/Archetypes.
>
> I think this is far too early.
>
> I'm all for starting the work on the dependency reduction stuff again,
> so this might become feasible at some point. But it's a ton of work -
> in the work I did, I still had the testing dependencies on
> PloneTestCase, as those where too much work to get rid of. Rewriting
> all tests using plone.app.testing and adjusting them to work without
> any type of default content or workflow is probably the best way
> forward here.

OK, so removing the ATContentTypes/Archetypes dependencies looks too
difficult for now. What would you think about just splitting off the
truly optional packages for now?

* Products.CMFPlacefulWorkflow
* kupu
* plone.app.openid
* plone.app.iterate
* and any other optional packages we deem core to Plone.

Laurence

------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers

[David Glick (GW)]

On 7/24/10 2:06 PM, Laurence Rowe wrote:

> On 24 July 2010 21:14, Hanno Schlichting <[hidden email]> wrote:
>  
>> On Sat, Jul 24, 2010 at 9:29 PM, Laurence Rowe <[hidden email]> wrote:
>>    
>>> 2. With the new collections implementation, plone.app.collection, it
>>> should become practical to build a site completely without Archetypes.
>>> The only dependency on ATContentTypes/Archetypes in CMFPlone seems to
>>> be the default profile.
>>>      
>> Oh, no, far from it. The dependency reduction work I did last year
>> didn't get merged.
>>    

Are you sure? I think some of got included when I cut the branches for
Plone 4. There is certainly some that didn't though, including the
problems with Archetypes that you mentioned.

>> There's a ton of circular dependencies all the way around. A simple
>> one is in PloneTestCase that insists on creating a self.folder Members
>> folder. The only folder implementation we have comes from
>> plone.app.folder these days, which depends on Archetypes.
>>
>> There's dependencies in all likely and unlikely places. Like the
>> markup control panel depending on Products.Archetypes.mimetype_utils.
>> Or plone.app.form containing kss support code and plone.app.kss
>> depending on Archetypes for some helper functions. plone.app.portlets
>> does a ZCML registrations for ATCTMixin, ... the list goes on and on.
>> This isn't impossible to solve, I did that once already. It's just a
>> lot of changes in almost all distributions we have. Doing that work on
>> dedicated PLIP branches for each distribution is quite a bit of an
>> overhead.
>>    

Which isn't necessarily an argument against it, if someone is willing to
do the work...

>>> For the above reasons I think that the current ``Plone`` package
>>> (containing Products.CMFPlone) should be renamed to ``PloneCore``.
>>> This package can drop the optional dependencies and
>>> ATContentTypes/Archetypes.
>>>      
>> I think this is far too early.
>>
>> I'm all for starting the work on the dependency reduction stuff again,
>> so this might become feasible at some point. But it's a ton of work -
>> in the work I did, I still had the testing dependencies on
>> PloneTestCase, as those where too much work to get rid of. Rewriting
>> all tests using plone.app.testing and adjusting them to work without
>> any type of default content or workflow is probably the best way
>> forward here.
>>    
> OK, so removing the ATContentTypes/Archetypes dependencies looks too
> difficult for now. What would you think about just splitting off the
> truly optional packages for now?
>
> * Products.CMFPlacefulWorkflow
> * kupu
> * plone.app.openid
> * plone.app.iterate
> * and any other optional packages we deem core to Plone.
>  

+1 from me. I've wanted a way to install a "leaner" Plone before.

----------
David Glick
 Web Developer
 [hidden email]
 206.286.1235x32

Groundwire: You Are Connected
 http://groundwire.org               
------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers

[Wichert Akkerman]

On 2010-7-25 02:30, David Glick wrote:

> On 7/24/10 2:06 PM, Laurence Rowe wrote:
>> On 24 July 2010 21:14, Hanno Schlichting<[hidden email]>  wrote:
>>
>>> On Sat, Jul 24, 2010 at 9:29 PM, Laurence Rowe<[hidden email]>  wrote:
>>>
>>>> 2. With the new collections implementation, plone.app.collection, it
>>>> should become practical to build a site completely without Archetypes.
>>>> The only dependency on ATContentTypes/Archetypes in CMFPlone seems to
>>>> be the default profile.
>>>>
>>> Oh, no, far from it. The dependency reduction work I did last year
>>> didn't get merged.
>>>
> Are you sure? I think some of got included when I cut the branches for
> Plone 4. There is certainly some that didn't though, including the
> problems with Archetypes that you mentioned.
>>> There's a ton of circular dependencies all the way around. A simple
>>> one is in PloneTestCase that insists on creating a self.folder Members
>>> folder. The only folder implementation we have comes from
>>> plone.app.folder these days, which depends on Archetypes.
>>>
>>> There's dependencies in all likely and unlikely places. Like the
>>> markup control panel depending on Products.Archetypes.mimetype_utils.
>>> Or plone.app.form containing kss support code and plone.app.kss
>>> depending on Archetypes for some helper functions. plone.app.portlets
>>> does a ZCML registrations for ATCTMixin, ... the list goes on and on.
>>> This isn't impossible to solve, I did that once already. It's just a
>>> lot of changes in almost all distributions we have. Doing that work on
>>> dedicated PLIP branches for each distribution is quite a bit of an
>>> overhead.
>>>
> Which isn't necessarily an argument against it, if someone is willing to
> do the work...
>>>> For the above reasons I think that the current ``Plone`` package
>>>> (containing Products.CMFPlone) should be renamed to ``PloneCore``.
>>>> This package can drop the optional dependencies and
>>>> ATContentTypes/Archetypes.
>>>>
>>> I think this is far too early.
>>>
>>> I'm all for starting the work on the dependency reduction stuff again,
>>> so this might become feasible at some point. But it's a ton of work -
>>> in the work I did, I still had the testing dependencies on
>>> PloneTestCase, as those where too much work to get rid of. Rewriting
>>> all tests using plone.app.testing and adjusting them to work without
>>> any type of default content or workflow is probably the best way
>>> forward here.
>>>
>> OK, so removing the ATContentTypes/Archetypes dependencies looks too
>> difficult for now. What would you think about just splitting off the
>> truly optional packages for now?
>>
>> * Products.CMFPlacefulWorkflow
>> * kupu
>> * plone.app.openid
>> * plone.app.iterate
>> * and any other optional packages we deem core to Plone.
>>
> +1 from me. I've wanted a way to install a "leaner" Plone before.

Other parts that I would like to see removed:

* plone.*.contentrules
* plone.*.portlets
* plone.*kss
* plone.app.redirector


Wichert.

--
Wichert Akkerman <[hidden email]>   It is simple to make things.
http://www.wiggy.net/                  It is hard to make things simple.

------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers

[Hanno Schlichting-4]

On Sun, Jul 25, 2010 at 2:30 AM, David Glick <[hidden email]> wrote:
> On 7/24/10 2:06 PM, Laurence Rowe wrote:
>> On 24 July 2010 21:14, Hanno Schlichting <[hidden email]> wrote:
>>> Oh, no, far from it. The dependency reduction work I did last year
>>> didn't get merged.
>>>
> Are you sure? I think some of got included when I cut the branches for
> Plone 4. There is certainly some that didn't though, including the
> problems with Archetypes that you mentioned.

Yes, some of it got included. But most of it didn't. Like the new
plone.navigation package to move commonly used interfaces out of
plone.app code (like INavigationRoot, INonStructuralFolder,
IHideFromBreadcrumbs, ...). We can start the work on this again and
I'm happy to help, but I won't have time to do it for 4.1.

>> OK, so removing the ATContentTypes/Archetypes dependencies looks too
>> difficult for now. What would you think about just splitting off the
>> truly optional packages for now?
>>
>> * Products.CMFPlacefulWorkflow
>> * kupu
>> * plone.app.openid
>> * plone.app.iterate
>> * and any other optional packages we deem core to Plone.
>>
> +1 from me. I've wanted a way to install a "leaner" Plone before.

Yes, I think this could be a good start. It also provides us with a
path forward, as we have a clear place to put optional things. Maybe
someone would finally be willing to PLIP a "Make KSS optional" ;)

And to bring up the bikeshed, I'd probably call the distribution
actually containing the CMFPlone code "Products.CMFPlone", so the
distribution and package names match once again. "Plone" can continue
to be the visible meta package.

The "Plone" distribution would probably still need to contain some
metadata, as it would still provide the canonical version number for a
Plone release. The only downside is that this makes the release
managers job more cumbersome, as he'll most often have to release all
of Plone, plone.app.upgrade and "Products.CMFPlone" for any new
release.

Hanno

------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers

[Wichert Akkerman]

On 2010-7-25 11:12, Hanno Schlichting wrote:

> On Sun, Jul 25, 2010 at 2:30 AM, David Glick<[hidden email]>  wrote:
>> On 7/24/10 2:06 PM, Laurence Rowe wrote:
>>> On 24 July 2010 21:14, Hanno Schlichting<[hidden email]>  wrote:
>>>> Oh, no, far from it. The dependency reduction work I did last year
>>>> didn't get merged.
>>>>
>> Are you sure? I think some of got included when I cut the branches for
>> Plone 4. There is certainly some that didn't though, including the
>> problems with Archetypes that you mentioned.
>
> Yes, some of it got included. But most of it didn't. Like the new
> plone.navigation package to move commonly used interfaces out of
> plone.app code (like INavigationRoot, INonStructuralFolder,
> IHideFromBreadcrumbs, ...). We can start the work on this again and
> I'm happy to help, but I won't have time to do it for 4.1.
>
>>> OK, so removing the ATContentTypes/Archetypes dependencies looks too
>>> difficult for now. What would you think about just splitting off the
>>> truly optional packages for now?
>>>
>>> * Products.CMFPlacefulWorkflow
>>> * kupu
>>> * plone.app.openid
>>> * plone.app.iterate
>>> * and any other optional packages we deem core to Plone.
>>>
>> +1 from me. I've wanted a way to install a "leaner" Plone before.
>
> Yes, I think this could be a good start. It also provides us with a
> path forward, as we have a clear place to put optional things. Maybe
> someone would finally be willing to PLIP a "Make KSS optional" ;)
>
> And to bring up the bikeshed, I'd probably call the distribution
> actually containing the CMFPlone code "Products.CMFPlone", so the
> distribution and package names match once again. "Plone" can continue
> to be the visible meta package.
>
> The "Plone" distribution would probably still need to contain some
> metadata, as it would still provide the canonical version number for a
> Plone release. The only downside is that this makes the release
> managers job more cumbersome, as he'll most often have to release all
> of Plone, plone.app.upgrade and "Products.CMFPlone" for any new
> release.

Personally I would move plone.app.upgrade into the Plone egg. I don't
see the point of always having to release multiple eggs in sync. To me
that suggests that the distribution split is not correct. I also
strongly prefer that a 'Plone' install is a minimal Plone and does not
ship with lots of optional add-ons. For me those are things installers
can add, and perhaps a separate PloneExtras package.

Wichert.

--
Wichert Akkerman <[hidden email]>   It is simple to make things.
http://www.wiggy.net/                  It is hard to make things simple.

------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers

[Hanno Schlichting-4]

On Sun, Jul 25, 2010 at 11:25 AM, Wichert Akkerman <[hidden email]> wrote:
> Personally I would move plone.app.upgrade into the Plone egg. I don't
> see the point of always having to release multiple eggs in sync. To me
> that suggests that the distribution split is not correct.

The split was done under the assumption, that maintenance releases
would almost never need any upgrade code. If that turns out to be
true, is still to be seen, as we haven't gotten 4.0.1, 4.0.2, ..
releases yet. For the very same reason we decoupled the metadata
profile number from the software version.

The other reason for moving it to its own distribution was to avoid
extra dependencies. For example SecureMailHost is only needed for
upgrading. The same should be true for contentmigration and kupu. The
upgrade code also tends to have lots of dependencies on things like
CMFEditions, CMFDiffTool, kss, Archetypes, ... all things we might
want to make optional. Having the code in a separate distribution
actually helps the proposal under discussion a lot ;)

> I also
> strongly prefer that a 'Plone' install is a minimal Plone and does not
> ship with lots of optional add-ons. For me those are things installers
> can add, and perhaps a separate PloneExtras package.

I think that's a bad choice from a marketing perspective. "Plone"
should always be the full featured end-user friendly version. Most
end-users will want to install this version. It's much easier to tell
our advanced integrators and developers about a leaner way to install
"Plone light". For example I'd hate to see some journalist review
stating that "Plone" comes without versioning support. Whatever we
ship and advertise as "Plone" should be the real deal, which is
identical to our installers.

Hanno

------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers

[Wichert Akkerman]

On 2010-7-25 11:48, Hanno Schlichting wrote:

> On Sun, Jul 25, 2010 at 11:25 AM, Wichert Akkerman<[hidden email]>  wrote:
>> Personally I would move plone.app.upgrade into the Plone egg. I don't
>> see the point of always having to release multiple eggs in sync. To me
>> that suggests that the distribution split is not correct.
>
> The split was done under the assumption, that maintenance releases
> would almost never need any upgrade code. If that turns out to be
> true, is still to be seen, as we haven't gotten 4.0.1, 4.0.2, ..
> releases yet. For the very same reason we decoupled the metadata
> profile number from the software version.
>
> The other reason for moving it to its own distribution was to avoid
> extra dependencies. For example SecureMailHost is only needed for
> upgrading. The same should be true for contentmigration and kupu. The
> upgrade code also tends to have lots of dependencies on things like
> CMFEditions, CMFDiffTool, kss, Archetypes, ... all things we might
> want to make optional. Having the code in a separate distribution
> actually helps the proposal under discussion a lot ;)
>
>> I also
>> strongly prefer that a 'Plone' install is a minimal Plone and does not
>> ship with lots of optional add-ons. For me those are things installers
>> can add, and perhaps a separate PloneExtras package.
>
> I think that's a bad choice from a marketing perspective. "Plone"
> should always be the full featured end-user friendly version. Most
> end-users will want to install this version. It's much easier to tell
> our advanced integrators and developers about a leaner way to install
> "Plone light". For example I'd hate to see some journalist review
> stating that "Plone" comes without versioning support. Whatever we
> ship and advertise as "Plone" should be the real deal, which is
> identical to our installers.

How many journalists do you expect not to use an installer?

Wichert.

--
Wichert Akkerman <[hidden email]>   It is simple to make things.
http://www.wiggy.net/                  It is hard to make things simple.

------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers

[Martin Aspeli]

On 25 July 2010 17:48, Hanno Schlichting <[hidden email]> wrote:

> On Sun, Jul 25, 2010 at 11:25 AM, Wichert Akkerman <[hidden email]> wrote:
>> Personally I would move plone.app.upgrade into the Plone egg. I don't
>> see the point of always having to release multiple eggs in sync. To me
>> that suggests that the distribution split is not correct.
>
> The split was done under the assumption, that maintenance releases
> would almost never need any upgrade code. If that turns out to be
> true, is still to be seen, as we haven't gotten 4.0.1, 4.0.2, ..
> releases yet. For the very same reason we decoupled the metadata
> profile number from the software version.
>
> The other reason for moving it to its own distribution was to avoid
> extra dependencies. For example SecureMailHost is only needed for
> upgrading. The same should be true for contentmigration and kupu. The
> upgrade code also tends to have lots of dependencies on things like
> CMFEditions, CMFDiffTool, kss, Archetypes, ... all things we might
> want to make optional. Having the code in a separate distribution
> actually helps the proposal under discussion a lot ;)
>
>> I also
>> strongly prefer that a 'Plone' install is a minimal Plone and does not
>> ship with lots of optional add-ons. For me those are things installers
>> can add, and perhaps a separate PloneExtras package.
>
> I think that's a bad choice from a marketing perspective. "Plone"
> should always be the full featured end-user friendly version. Most
> end-users will want to install this version. It's much easier to tell
> our advanced integrators and developers about a leaner way to install
> "Plone light". For example I'd hate to see some journalist review
> stating that "Plone" comes without versioning support. Whatever we
> ship and advertise as "Plone" should be the real deal, which is
> identical to our installers.

+sys.maxint

Anything else is just stupidity. Those who know enough about Plone to
know that they want a pared-down version know how to install
Products.CMFPlone instead of the Plone egg. Those who don't, need to
get the full product when they ask for "Plone", journalists or not.

Martin

------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers