Move core plugins into separate packages #1359

Closed
ojii opened this Issue Jul 24, 2012 · 9 comments

Comments

Projects
None yet
4 participants
@ojii
Collaborator

ojii commented Jul 24, 2012

I propose moving all core plugins into separate packages, so they can have their own release cycles, own backwards compatibility policies and make it clearer that those are just some plugins people can use, but don't have to. Ideally this would encourage someone to write a better link plugin for example that then becomes the de-facto standard.

The problem right now is that the plugins are bound by our release cycle and backwards compatibility policy. Built-in plugins never change or evolve. But since they're shipped with the CMS, people are likely to use them "because they're there" instead of realizing that they're not required and can just be replaced/ignored.

Technically this would be done using "Namespace Packages" (see http://packages.python.org/distribute/setuptools.html#namespace-packages) to preserve the cms.plugins namespace in those packages to make the transition easier. It should be clearly noted in the documentation that this is NOT recommended behavior for plugins and 3rd party plugins should use their own namespaces (ideally cmsplugin_<plugin name>).

@kezabelle

This comment has been minimized.

Show comment Hide comment
@kezabelle

kezabelle Jul 25, 2012

Contributor

+1 on the idea, but is it sustainable? Flask, for example, moved away from storing extensions in flask.ext (though imports from there should still work, through the extension import transition) because of life getting problematic with installation and upgrades (but not easy_install?) - I have no idea if they used setuptools "Namespace Packages", so I bring it up merely to ensure that it's workable.

Contributor

kezabelle commented Jul 25, 2012

+1 on the idea, but is it sustainable? Flask, for example, moved away from storing extensions in flask.ext (though imports from there should still work, through the extension import transition) because of life getting problematic with installation and upgrades (but not easy_install?) - I have no idea if they used setuptools "Namespace Packages", so I bring it up merely to ensure that it's workable.

@ojii

This comment has been minimized.

Show comment Hide comment
@ojii

ojii Jul 25, 2012

Collaborator

again, this namespace hack should only be used by the (by then former) core plugins. The plugins could then start using a nani/hvad like approach (move to new package name, shadow the old package cluttered with warnings) to transition to the canonical plugin names.

Collaborator

ojii commented Jul 25, 2012

again, this namespace hack should only be used by the (by then former) core plugins. The plugins could then start using a nani/hvad like approach (move to new package name, shadow the old package cluttered with warnings) to transition to the canonical plugin names.

@ojii

This comment has been minimized.

Show comment Hide comment
@ojii

ojii Aug 2, 2012

Collaborator

Played around with it a bit and this is how you can do namespaced packages in Python: https://github.com/ojii/python-namespaced-packages-example

Not 100% sure this is how you're SUPPOSED to do them, but seems to work.

Collaborator

ojii commented Aug 2, 2012

Played around with it a bit and this is how you can do namespaced packages in Python: https://github.com/ojii/python-namespaced-packages-example

Not 100% sure this is how you're SUPPOSED to do them, but seems to work.

@digi604

This comment has been minimized.

Show comment Hide comment
@digi604

digi604 Jun 26, 2013

Contributor

I think breaking imports in plugins for 3.0 is ok if we remove them. Most removed plugins will die anyway and there are better alternatives anyway.

Contributor

digi604 commented Jun 26, 2013

I think breaking imports in plugins for 3.0 is ok if we remove them. Most removed plugins will die anyway and there are better alternatives anyway.

@ojii

This comment has been minimized.

Show comment Hide comment
@ojii

ojii Jun 26, 2013

Collaborator

So break backwards compatibility despite having a clear way not to? Doesn't
sound right in my book. It means you can't upgrade easily, and we want
users to upgrade
On 27 Jun 2013 00:34, "Patrick Lauber" notifications@github.com wrote:

I think breaking imports in plugins for 3.0 is ok if we remove them. Most
removed plugins will die anyway and there are better alternatives anyway.


Reply to this email directly or view it on GitHubhttps://github.com/divio/django-cms/issues/1359#issuecomment-20056041
.

Collaborator

ojii commented Jun 26, 2013

So break backwards compatibility despite having a clear way not to? Doesn't
sound right in my book. It means you can't upgrade easily, and we want
users to upgrade
On 27 Jun 2013 00:34, "Patrick Lauber" notifications@github.com wrote:

I think breaking imports in plugins for 3.0 is ok if we remove them. Most
removed plugins will die anyway and there are better alternatives anyway.


Reply to this email directly or view it on GitHubhttps://github.com/divio/django-cms/issues/1359#issuecomment-20056041
.

@yakky

This comment has been minimized.

Show comment Hide comment
@yakky

yakky Jun 26, 2013

Contributor

Probably for any removal a clear upgrade path should be documented.
Not sure it's really needed to use namespace and make it completely transparent., but definitely not leaving users on their own.

Contributor

yakky commented Jun 26, 2013

Probably for any removal a clear upgrade path should be documented.
Not sure it's really needed to use namespace and make it completely transparent., but definitely not leaving users on their own.

@ojii

This comment has been minimized.

Show comment Hide comment
@ojii

ojii Jun 27, 2013

Collaborator

My issue is the data you loose during the upgrade if we don't keep the all
names.
On 27 Jun 2013 04:49, "Iacopo Spalletti" notifications@github.com wrote:

Probably for any removal a clear upgrade path should be documented.
Not sure it's really needed to use namespace and make it completely
transparent., but definitely not leaving users on their own.


Reply to this email directly or view it on GitHubhttps://github.com/divio/django-cms/issues/1359#issuecomment-20074966
.

Collaborator

ojii commented Jun 27, 2013

My issue is the data you loose during the upgrade if we don't keep the all
names.
On 27 Jun 2013 04:49, "Iacopo Spalletti" notifications@github.com wrote:

Probably for any removal a clear upgrade path should be documented.
Not sure it's really needed to use namespace and make it completely
transparent., but definitely not leaving users on their own.


Reply to this email directly or view it on GitHubhttps://github.com/divio/django-cms/issues/1359#issuecomment-20074966
.

@yakky

This comment has been minimized.

Show comment Hide comment
@yakky

yakky Jun 27, 2013

Contributor

Being data-compatible it's actually easy, or am I missing something?
Moving existing plugins outside django CMS into separate applications (as for the text plugin) won't change the table names, as long as the model names stay the same, am I right?

Contributor

yakky commented Jun 27, 2013

Being data-compatible it's actually easy, or am I missing something?
Moving existing plugins outside django CMS into separate applications (as for the text plugin) won't change the table names, as long as the model names stay the same, am I right?

@digi604

This comment has been minimized.

Show comment Hide comment
@digi604

digi604 Feb 7, 2014

Contributor

fixed

Contributor

digi604 commented Feb 7, 2014

fixed

@digi604 digi604 closed this Feb 7, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment