Determine the actual dependencies for the various plone.* packages

[GoogleCodeExporter]

Python's "setuptools" package supports dependency management. With Plone 3, 
several packages 
in the plone.* namespace (such as plone.portlets or plone.memoize, but *not* 
those in the 
plone.app.* namespace, such as plone.app.portlets) are intended for re-use 
outside Plone. Unfortunately, some of these have implicit dependencies.

The task: Analyse the plone.* modules that ship with Plone 3 and update their 
setup.py to list (under 
"install_requires") any and all dependencies. The dependencies must exist in 
the Python Package 
Index.

Original issue reported on code.google.com by optil...@gmail.com on 19 Nov 2007 at 11:16

[GoogleCodeExporter]

Original comment by l...@gmail.com on 27 Nov 2007 at 7:06

• Changed state: Open
• Added labels: Complex, 5-day
• Removed labels: Medium

[GoogleCodeExporter]

Do I understand this task right, that it's basically just crawling through (or
writing a crawler that inspects) every plone.* package, looking at every file 
for
foreign imports (what about Zope packages such as zope.interface?) and writing 
them
down in setup.py?

PS. In my first analysis I stumbled upon plone.folder which pulls in 
AccessControl.
Seems this has been overridden by Products.PluggagbleAuthService (but PyPI 
links to
this package when searching for AccessControl). What to do here?

Original comment by lehman...@gmail.com on 11 Jan 2008 at 12:30

[GoogleCodeExporter]

Yes, you understand correctly. We need to populate the install_requires lines 
in each of the plone.* packages that 
shop with Plone, by adding proper dependency information.

Note that some things, such as AccessControl, are actually part of Zope 2. Zope 
2 isn't an egg (yet?) so there's no 
specific package. AccessControl is not overridden by PluggableAuthService 
(PAS), though PAS does amend and 
extend AccessControl in that it implements a more flexible security model.

Original comment by optil...@gmail.com on 11 Jan 2008 at 12:50

[GoogleCodeExporter]

What's with those packages not included in `ploneout`? 

And there seems to be a PyPI entry "Zope", so AccessControl should just be 
aliased by
this package? Thanks for your answers so far, when these last bits are 
clarified, I
guess I'll claim it. :)

Original comment by lehman...@gmail.com on 12 Jan 2008 at 11:45

[GoogleCodeExporter]

For the moment, the packages that are part of Plone core (i.e. those included 
in ploneout, or installed using 
plone.recipe.plone) are the most important.

There may be a PyPI entry for Zope 2, but it's not an egg, and so setuptools 
would fail to install it. Only packages 
with actual, released eggs should be included as dependencies.

Original comment by optil...@gmail.com on 13 Jan 2008 at 12:07

[GoogleCodeExporter]

I claim this task.

Original comment by lehman...@gmail.com on 13 Jan 2008 at 9:47

[GoogleCodeExporter]

Cool! :)

Please either submit patches, updated setup.py files or, if you have Plone 
contributor access, branches in svn. 
Please also make sure you test this with ploneout (or a regular buidout) so 
that we can make sure setuptools 
doesn't complain.

Original comment by optil...@gmail.com on 13 Jan 2008 at 10:45

• Changed state: Claimed
• Added labels: ClaimedBy-lehmannro

[GoogleCodeExporter]

One minor issue that came up during the process: Products.Five is a pretty 
common
import but not in the package index. I left it out everywhere for now. Is this 
okay?

I attached a preliminary diff and would like to have a review on this. I had to 
issue
``svn diff ploneout/src/plone.*`` to get this since SVN does not seem to 
properly
create diffs for externals.

Cheers,

Original comment by lehman...@gmail.com on 13 Jan 2008 at 11:04

Attachments:

• plone.patch

[GoogleCodeExporter]

And now, after the gruntwork of collecting the dependencies, the tiny bits I 
missed.
;-) Building with ploneout-buildout works fine.

Original comment by lehman...@gmail.com on 13 Jan 2008 at 11:27

Attachments:

• plonesetup.patch

[GoogleCodeExporter]

Great work, this is closed.

Original comment by mw4...@googlemail.com on 21 Jan 2008 at 1:28

• Changed state: Closed