[ZCM] [ZC] 2276/ 9 Comment "Zope 2 test.py and eggs"

[Collector: Zope Bugs, Features, and Patches ...]

Issue #2276 Update (Comment) "Zope 2 test.py and eggs"
 Status Pending, Zope/bug medium
To followup, visit:
  http://www.zope.org/Collectors/Zope/2276

==============================================================
= Comment - Entry #9 by nouri on Feb 10, 2007 3:19 pm


Uploaded:  "Products.diff"
 - http://www.zope.org/Collectors/Zope/2276/Products.diff/view
The $SOFTWARE_HOME/Products package needs to be a namespace package as we decided.  There is a problem with this, however: It contains code, which is not allowed for a namespace package.

The attached patch attempts to resolve this issue by moving the '__ac_permissions__' definition into the AccessControl package.  Maybe there is a better place for this.  But AccessControl/__init__.py seems to work fine for me.
________________________________________
= Comment - Entry #8 by nouri on Feb 7, 2007 10:05 am

Great news.  I will try and fix this in the next couple of days.  Thanks for your support.

And yes, I should have commit access.

________________________________________
= Comment - Entry #7 by philikon on Feb 7, 2007 9:52 am

Good idea, Rocky. If that should indeed work, Daniel, I think we should be able to sneak this into the Zope 2 (with proper try:/except: clauses if setuptools aren't installed). Are you a committer yet? :)
________________________________________
= Comment - Entry #6 by nouri on Feb 7, 2007 9:28 am

You're right!  That sounds like the right solution.
________________________________________
= Comment - Entry #5 by rocky on Feb 7, 2007 8:18 am

Perhaps the reason it doesn't work is because zope's SOFTWARE_HOME/Products directory doesn't declare itself as a namespace package and if we fixed that we could continue prepending it to sys.path ?

That is, since it has no namespace package declaration, it doesn't pick up additional Products paths.
________________________________________
= Comment - Entry #4 by philikon on Feb 7, 2007 7:19 am

I realize that, I still don't like it. I don't want it to pick up any other Zope libraries I have accidentally set in my PYTHONPATH. When I execute test.py from a Zope sandbox, it should *always* use the libraries from that sandbox, both SOFTWARE_HOME AND INSTANCE_HOME.
________________________________________
= Comment - Entry #3 by nouri on Feb 7, 2007 5:17 am

> = Comment - Entry #2 by philikon on Feb 6, 2007 7:37 pm
> 
> I don't think I like point 1). I want scripts like test.py to make sure
>   that they take their associated sandbox OVER anything I've set in my
>   PYTHONPATH. That's why I think it makes sense that they prepend to
>   sys.path.

Note that this puts $SOFTWARE_HOME/lib/python, not INSTANCE_HOME at the end of sys.path.  Maybe we should only do this if it's used inside an INSTANCE_HOME, i.e. ``if ihome``?

________________________________________
= Comment - Entry #2 by philikon on Feb 6, 2007 7:37 pm

I don't think I like point 1). I want scripts like test.py to make sure that they take their associated sandbox OVER anything I've set in my PYTHONPATH. That's why I think it makes sense that they prepend to sys.path.
________________________________________
= Request - Entry #1 by nouri on Feb 6, 2007 6:47 pm


Uploaded:  "test.py.diff"
 - http://www.zope.org/Collectors/Zope/2276/test.py.diff/view
Attached is quite a small patch to test.py that does two things:

  1) It appends the SOFTWARE_HOME path to the end of sys.path, instead of putting it in front of other paths.  This allows subpackages of the 'Products' namespace package to be found.

  2) It adds default arguments to the testrunner in the test.py script so that other paths in sys.path that start with the instance's home path are included in the --test-path arguments to the testrunner.  This allows tests from eggs that are installed in the instance's lib/python to be run.

I'm not exactly sure about the implications of (1), but (2) certainly is a big step towards comfortable working with Zope 2 in a workingenv or virtual-python setting.

I think the performance impact of searching those additional directories (if they are there at all) can be neglected.
==============================================================