Local commands broken by external dependencies in setup.py

[cewing]

When attempting to run local commands on a freshly created dexterity package (say for creating a new dexterity content type in the new package), I get the following error:

pkg_resources.DistributionNotFound: plone.namedfile[blobs]: Not Found for: my.package (did you run python setup.py develop?)

This generally happens because the named package is not currently available to Paste in the context of the current working set.

I'm not completely clear on how to deal with this. The dependency on plone.namedfile[blobs] is declared in the setup.py of the template. Is this a hard dependency for all dexterity content types? Is there some way we might remove this?

[davisagli]

It's a dependency of any Dexterity type that has file/image fields and wants to make sure they are the blob variety.

Why the heck does Paste need to install the working set of the package being skeletized in order to run local commands?

[cewing]

At the point where we create the dexterity package, and have not yet actually created any content types, we have no file or image fields to worry about, right? So we should be able to defer inserting this dependency until we actually have a field that requires it?

My thought is that it should be inserted by a local command creating a schema field, or not at all.

As for why Paste requires this, I have no idea. I suspect it's just a side effect of the way Paste and pkg_resources interact with each other. :(

[davisagli]

I'd call it totally broken, not just a side effect. I thought there was work underway to support local commands without using Paste?

[cewing]

yep, totally broken it is.

in fact, the local commands don't work even with the dependency on plone.app.dexterity. While we can do without an immediate dependency on plone.namedfile[blobs], the dependency on dexterity is more fundamental.

This adds a lot of weight to fixing our Paste problem. See this templer.core issue for progress on that front.

[miohtama]

I wouldn't call it totally broken, because you can still use it, as long as you do like it is written in the documentation

This is how you it should work

1. Your package is listed in buildout and you must run buildout after generating your package for the first time

2. You use buildout based ZopeSkel

3. Instructions tell that you must list your egg in buildout and you must use ZopeSkel from buildout

4. ZopeSkel sees eggs from buildout, does not download dependencies and everything works fine

http://developer.plone.org/getstarted/paste.html#adding-zopeskel-to-your-buildout

Do not use ZopeSkel with local commands independently installed in virtualenv or such. It is clearly stated on d.p.org.

Please tell me if this process fails with templer.dexterity as this is rhe documented process (fi there is any other documentation I will make sure it disappears).

[pigeonflight]

For me the solution was to ensure that my [zopeskel] entry in buildout made reference to the same eggs that my instance did (the unified installer does this for you by including ${buildout:eggs}, so for the unified installer in the develop.cfg file you'll see a zopeskel entry like this:

[zopeskel]
recipe = zc.recipe.egg
eggs =
    ZopeSkel <= 2.99
    Paste
    PasteDeploy
    PasteScript
    zopeskel.diazotheme
    zopeskel.dexterity
    zest.releaser
   ${buildout:eggs}

but my instance doesn't rely on ${buildout:eggs} and so that didn't work for me with my buildout.

My buildout was generated using plock and the plock approach uses different variable names in some cases for example the instance in plock is called [plone]. To fix my issue I had to add a zopeskel entry that referenced ${plone:eggs} like this:

[zopeskel]
recipe = zc.recipe.egg
eggs =
    ZopeSkel <= 2.99
    Paste
    PasteDeploy
    PasteScript
    zopeskel.diazotheme
    zopeskel.dexterity
    zest.releaser
   ${plone:eggs}

I also had to pin very specific versions

[versions]
setuptools = 0.7.2
zc.buildout = 2.2.1 
ZopeSkel = 2.21.2
Cheetah = 2.2.1
Products.DocFinderTab = 1.0.5
buildout.sanitycheck = 1.0b1
collective.recipe.backup = 2.17
plone.recipe.unifiedinstaller = 4.3.1
zopeskel.dexterity = 1.5.4.1
zopeskel.diazotheme = 1.1

Then localcommands worked as expected.