Make plone.protect a soft dependency.

[thet]

This allows to use this package in setups without the Plone stack. Fixes plone/Products.CMFPlone#1311

[thet]

http://jenkins.plone.org/job/pull-request-5.0/675/

[papachoco]

Thanks a lot

[mauritsvanrees]

+1

[jensens]

Catching ImportError is not recommended http://ploneapi.readthedocs.org/en/latest/contribute/conventions.html#about-imports (see #4)

[thet]

There was a discussion elsewhere - using pkg_resources is slower than just using ImportError. It does only mask errors in the package, from which we are importing, which should catched via tests anyways. Aslo depending on pkg_resources, which comes from setuptools does not feel right within production code (IMO).
Where was this discussion .... can't really remember...

[jensens]

discussion result was to stick to plone api conventions, some millis one time at startup vs. hours of debugging: latter won.
Also all production code needs setuptools. I.e. to load fs-resources if a package is zip-safe (recommended to write your code this way).

[thet]

IIRC, there was a bigger motion to use ImportError, but we did not discuss this to the end.
Personally, I dislike the pkg_resource way, because I always have to look it up vs using the easy to remember Python syntax for that.
Can you remember, where this discussion took place on github? I remember @gforcada, @davisagli and me were discussing that.

[mauritsvanrees]

That would be this one: plone/plone.api#217
which links to this: plone/plone.app.event@a17c9e1

[thet]

Thanks @mauritsvanrees
See, not discussed to the end. There is still room for discussion, IMO. However, I've updated the pull-request.

[thet]

I've updated the pull request. I'll reopen plone/plone.api#217 for further discussion.