Re: [Framework-Team] Re: Organisation of Plone components in Collective and Plone svn
On Tue, 2006-05-02 at 01:08 +0200, Hanno Schlichting wrote: > Hi all. > > To summarize some of the discussion we had on IRC just now, here is our > current idea, for all those people not spending their life in online > channels ;) > > As an example we used the structure for the contextualhelp product, > which was developed at the sprint: > > This should go into the "http://svn.plone.org/svn/plone/"; repository > under the name "plone.contextualhelp": > > http://svn.plone.org/svn/plone/plone.contextualhelp/trunk > http://svn.plone.org/svn/plone/plone.contextualhelp/trunk/src > http://svn.plone.org/svn/plone/plone.contextualhelp/trunk/src/plone > http://svn.plone.org/svn/plone/plone.contextualhelp/trunk/src/plone/contextualhelp > > http://svn.plone.org/svn/plone/plone.contextualhelp/branches > http://svn.plone.org/svn/plone/plone.contextualhelp/tags > > The trunk folder itself should contain release scripts, like setup.py > and the real source should be in a /src subfolder. It has a plone > subfolder, so it is obvious that to import anything from this package > you have to use "from plone.contextualhelp import *". > > If we can agree on this, we should probably post this to the devel list > with some more explanation (which can grow into a chapter in the dev > manual ;) + 1 for me too! vds -- Vincenzo Di Somma REFLAB (Studio Associato) design, development and consulting T: +39 349 756 54 60 E: [EMAIL PROTECTED] W: www.reflab.com Weblog: http://www.reflab.com/blogs/vdsblog signature.asc Description: This is a digitally signed message part ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: Organisation of Plone components in Collective and Plone svn
On May 2, 2006, at 5:27 AM, Daniel Nouri wrote: Rocky Burt wrote: On Mon, 2006-01-05 at 19:20 -0700, Rob Miller wrote: On May 1, 2006, at 4:19 PM, Rocky Burt wrote: On Tue, 2006-02-05 at 01:08 +0200, Hanno Schlichting wrote: To summarize some of the discussion we had on IRC just now, here is our current idea, for all those people not spending their life in online channels ;) As an example we used the structure for the contextualhelp product, which was developed at the sprint: This should go into the "http://svn.plone.org/svn/plone/"; repository under the name "plone.contextualhelp": http://svn.plone.org/svn/plone/plone.contextualhelp/trunk http://svn.plone.org/svn/plone/plone.contextualhelp/trunk/src http://svn.plone.org/svn/plone/plone.contextualhelp/trunk/src/ plone http://svn.plone.org/svn/plone/plone.contextualhelp/trunk/src/ plone/contextualhelp http://svn.plone.org/svn/plone/plone.contextualhelp/branches http://svn.plone.org/svn/plone/plone.contextualhelp/tags The trunk folder itself should contain release scripts, like setup.py and the real source should be in a /src subfolder. It has a plone subfolder, so it is obvious that to import anything from this package you have to use "from plone.contextualhelp import *". If we can agree on this, we should probably post this to the devel list with some more explanation (which can grow into a chapter in the dev manual ;) +1 to all of this. Except of course for the line "from plone.contextualhelp import *". If I see code importing * I will promptly scream :) i'm okay with most of this, except for the extra 'plone' level in the src tree. it's implied in the plone.contextualhelp directory name, IMO, no need for an empty, duplicate folder level. I'm not sure of all the practical reasoning for requiring the 'plone' level in the src tree but all the regular python packaging I've seen that uses a toplevel package does provide that dir in their src directory so part of this would merely be for consistency's sake. Look at more of the zope.* whatever pkgs in svn.zope.org and see for yourself. Right, `plone` would be our namespace[1] package. This makes very much sense in the context of setuptools/distutils. (It's nice to know *why* zope3 people do the things they do ;) However, having src/ is really a matter of taste. ah, okay, well in that case i'd argue for 'plone' instead of 'src'. i could live with it as it's described above, so if there are good reasons to use the entire structure then fine, but if we can eliminate unnecessary directories then i'd rather do so. -r ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Organisation of Plone components in Collective and Plone svn
Rocky Burt wrote: > On Mon, 2006-01-05 at 19:20 -0700, Rob Miller wrote: > >>On May 1, 2006, at 4:19 PM, Rocky Burt wrote: >> >> >>>On Tue, 2006-02-05 at 01:08 +0200, Hanno Schlichting wrote: >>> To summarize some of the discussion we had on IRC just now, here is our current idea, for all those people not spending their life in online channels ;) As an example we used the structure for the contextualhelp product, which was developed at the sprint: This should go into the "http://svn.plone.org/svn/plone/"; repository under the name "plone.contextualhelp": http://svn.plone.org/svn/plone/plone.contextualhelp/trunk http://svn.plone.org/svn/plone/plone.contextualhelp/trunk/src http://svn.plone.org/svn/plone/plone.contextualhelp/trunk/src/plone http://svn.plone.org/svn/plone/plone.contextualhelp/trunk/src/ plone/contextualhelp http://svn.plone.org/svn/plone/plone.contextualhelp/branches http://svn.plone.org/svn/plone/plone.contextualhelp/tags The trunk folder itself should contain release scripts, like setup.py and the real source should be in a /src subfolder. It has a plone subfolder, so it is obvious that to import anything from this package you have to use "from plone.contextualhelp import *". If we can agree on this, we should probably post this to the devel list with some more explanation (which can grow into a chapter in the dev manual ;) >>> >>>+1 to all of this. Except of course for the line "from >>>plone.contextualhelp import *". If I see code importing * I will >>>promptly scream :) >> >>i'm okay with most of this, except for the extra 'plone' level in the >>src tree. it's implied in the plone.contextualhelp directory name, >>IMO, no need for an empty, duplicate folder level. > > > I'm not sure of all the practical reasoning for requiring the 'plone' > level in the src tree but all the regular python packaging I've seen > that uses a toplevel package does provide that dir in their src > directory so part of this would merely be for consistency's sake. > > Look at more of the zope.* whatever pkgs in svn.zope.org and see for > yourself. Right, `plone` would be our namespace[1] package. This makes very much sense in the context of setuptools/distutils. (It's nice to know *why* zope3 people do the things they do ;) However, having src/ is really a matter of taste. [1] http://peak.telecommunity.com/DevCenter/setuptools#namespace-packages ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: Organisation of Plone components in Collective and Plone svn
On May 1, 2006, at 4:19 PM, Rocky Burt wrote: On Tue, 2006-02-05 at 01:08 +0200, Hanno Schlichting wrote: To summarize some of the discussion we had on IRC just now, here is our current idea, for all those people not spending their life in online channels ;) As an example we used the structure for the contextualhelp product, which was developed at the sprint: This should go into the "http://svn.plone.org/svn/plone/"; repository under the name "plone.contextualhelp": http://svn.plone.org/svn/plone/plone.contextualhelp/trunk http://svn.plone.org/svn/plone/plone.contextualhelp/trunk/src http://svn.plone.org/svn/plone/plone.contextualhelp/trunk/src/plone http://svn.plone.org/svn/plone/plone.contextualhelp/trunk/src/ plone/contextualhelp http://svn.plone.org/svn/plone/plone.contextualhelp/branches http://svn.plone.org/svn/plone/plone.contextualhelp/tags The trunk folder itself should contain release scripts, like setup.py and the real source should be in a /src subfolder. It has a plone subfolder, so it is obvious that to import anything from this package you have to use "from plone.contextualhelp import *". If we can agree on this, we should probably post this to the devel list with some more explanation (which can grow into a chapter in the dev manual ;) +1 to all of this. Except of course for the line "from plone.contextualhelp import *". If I see code importing * I will promptly scream :) i'm okay with most of this, except for the extra 'plone' level in the src tree. it's implied in the plone.contextualhelp directory name, IMO, no need for an empty, duplicate folder level. -r ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Organisation of Plone components in Collective and Plone svn
On Tue, 2006-02-05 at 01:08 +0200, Hanno Schlichting wrote: > To summarize some of the discussion we had on IRC just now, here is our > current idea, for all those people not spending their life in online > channels ;) > > As an example we used the structure for the contextualhelp product, > which was developed at the sprint: > > This should go into the "http://svn.plone.org/svn/plone/"; repository > under the name "plone.contextualhelp": > > http://svn.plone.org/svn/plone/plone.contextualhelp/trunk > http://svn.plone.org/svn/plone/plone.contextualhelp/trunk/src > http://svn.plone.org/svn/plone/plone.contextualhelp/trunk/src/plone > http://svn.plone.org/svn/plone/plone.contextualhelp/trunk/src/plone/contextualhelp > > http://svn.plone.org/svn/plone/plone.contextualhelp/branches > http://svn.plone.org/svn/plone/plone.contextualhelp/tags > > The trunk folder itself should contain release scripts, like setup.py > and the real source should be in a /src subfolder. It has a plone > subfolder, so it is obvious that to import anything from this package > you have to use "from plone.contextualhelp import *". > > If we can agree on this, we should probably post this to the devel list > with some more explanation (which can grow into a chapter in the dev > manual ;) +1 to all of this. Except of course for the line "from plone.contextualhelp import *". If I see code importing * I will promptly scream :) - Rocky -- Rocky Burt ServerZen Software -- http://www.serverzen.com News About The Server -- http://www.serverzen.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Organisation of Plone components in Collective and Plone svn
Hi all. To summarize some of the discussion we had on IRC just now, here is our current idea, for all those people not spending their life in online channels ;) As an example we used the structure for the contextualhelp product, which was developed at the sprint: This should go into the "http://svn.plone.org/svn/plone/"; repository under the name "plone.contextualhelp": http://svn.plone.org/svn/plone/plone.contextualhelp/trunk http://svn.plone.org/svn/plone/plone.contextualhelp/trunk/src http://svn.plone.org/svn/plone/plone.contextualhelp/trunk/src/plone http://svn.plone.org/svn/plone/plone.contextualhelp/trunk/src/plone/contextualhelp http://svn.plone.org/svn/plone/plone.contextualhelp/branches http://svn.plone.org/svn/plone/plone.contextualhelp/tags The trunk folder itself should contain release scripts, like setup.py and the real source should be in a /src subfolder. It has a plone subfolder, so it is obvious that to import anything from this package you have to use "from plone.contextualhelp import *". If we can agree on this, we should probably post this to the devel list with some more explanation (which can grow into a chapter in the dev manual ;) Cheers, Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Organisation of Plone components in Collective and Plone svn
Well, this is a bit of a grey area. Based on how the zope3 naming conventions are going these days, this is what i would leans towards: This would be for the portlets project: svn/plone.portlet/src/plone/portlet/* This would be for the contextualhelp project: svn/plone.contextualhelp/src/plone/contextualhelp In other words, most of the 2nd level packages warrant their own projects and the toplevel svn directory name would actually be "plone.whatever". This convention can quickly be seen by perusing http://svn.zope.org/ An example would be http://svn.zope.org/zope.formlib/ Zope Corp even does this with their own pkgs which they prefix with zc.* - Rocky On Sun, 2006-30-04 at 23:01 +0100, Martin Aspeli wrote: > Hi guys, > > A lot of the Archipelago work, like plone.portlets (a top-level package on > itself?) and LinkIntegrity and ploneKukit landed in the Collective. I'm > not sure that's the optimal place for all of them. The things that are > part of plone core and are maintained as such should live in the main > plone repo, with the protection that enjoys. > > For example, I think we should have: > > plone/ > plone/ajax (for the kukit/bling stuff) > plone/portlets > plone/contextualrefs (to be broken out of contextualhelp) > plone/contextualhelp > > etc. > > the LinkIntegrity stuff may need to be moved, but I'm not quite sure. > > What's the Foundation's and our position on this? > > Martin > -- Rocky Burt ServerZen Software -- http://www.serverzen.com News About The Server -- http://www.serverzen.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
