[Cubicweb] CWEP 0004 - Cubes as distributions

Christophe de Vienne christophe at unlish.com
Thu Oct 23 10:20:57 CEST 2014

Hello Denis,

Thanks for the feedback !

Le 23/10/2014 08:56, Denis Laxalde a écrit :
> Hi Christophe,
> Quoting http://hg.logilab.org/review/cwep/file/tip/CWEP-004.rst:
>> The central idea is to use standard python packages as containers, 
>> and rely on
>> entry-points to discover the cubes.
> Does this mean that cubes will be install in site-packages? Something 
> like "/usr/lib/python2.7/dist-packages/cubes/" on a system installation?
Yes, although the "cubes" namespace is not mandatory. I would advise 
against it because it has little advantages, and I try to avoid 
namespaces before python 3.4, it is too much trouble (see the recent 
issues with the logilab namespace on ubuntu).

They could also be installed in a separate directory that would only 
need to be added to python path (no specific lookup, just plain 
pkg_resources handling of the packages).

> It seems to me that one of the "feature" of the current layout is that 
> cubes are somehow private Python packages that are only meant to be 
> used by a CubicWeb application.
Yes, but I do not think this privacy needs to be enforced that much.
It also can be a problem if I want to build an application that 
cherry-pick things in some cubes without loading them normally.

In the pyramid ecosystem, the pyramid extension simply have a "pyramid_" 
prefix to their module name, and it seems to be enough: a naming 
convention tells what is needed to the developper (same way prefixing 
attributes with "_" tells not to mess too much with it).

> The current layout probably has other advantages, it'd be nice if they 
> could be listed along with drawbacks.
This is where I need you guys :-)

>> This situation leads to several problematic situations, with no easy 
>> solution:
>> -   If modules are imported from one cube to another, multiple values in
>>     CUBES_PATH is not possible, because the root "cubes" directory is 
>> expected
>>     to be in the PYTHONPATH.
>>     This particular issue makes it difficult, if not impossible, to 
>> install
>>     cubes system-wide (or in a virtualenv) and work on cubes in a work
>>     directory.
> This is the workflow I use most of the times, and it just works fine 
> (most of the times ;)). Setting CW_MODE=user and 
> CW_CUBES_PATH=~/src/cw/cubes, one can certainly use system-wide cubes 
> along with cubes in the CW_CUBES_PATH, the latter being preferred in 
> case of redundant installation. I sometimes went into little problems 
> with this setup for testing (don't remember the details); so I 
> wouldn't say it works perfectly, but this is certainly not "difficult" 
> nor impossible.
I think it works as long as you don't do "from cubes.xxx import yyy", 
where the xxx cube is in the "wrong" cubes path.
This is something that is done often for testing, hence the problems you 
had (I guess).

It means that if we write a cube that import things from another cube, 
they need to be in the cubes path that correspond to the "cubes" module 
in sys.path.

In the end, it impose to developer to fully understand how cubes imports 
works, which is a little different from how standard packages work (and 
for no solid reason).

>> -   The (unperfect but popular) "develop" mode of setuptools and pip 
>> does not
>>     work. It can be worked around but it is a pain (See
>> http://lists.cubicweb.org/pipermail/cubicweb/2014-September/002160.html)
> So the development mode does not work out of the box, but wouldn't it 
> be possible to define a custom "develop" target that would make it 
> work with the current layout (maybe setting the "install-dir" 
> mentionned in the documentation).
I doubt that a sane way, working with on posix and win32 platform, 
exists. I would be pleased to be proved wrong though.

> If this is related to the "private" status of cubes in the current 
> layout that I mentioned above, do you know how other applications also 
> using "private modules/package" work with this development mode (if 
> they do)?
It is, partially, related to the "private" status of the cube.

As for other application, I can think of two examples: OpenERP and trac.
They both have "private" extensions. But to use them, they simply add 
their parent directory(ies) in the python path. There isn't an 
additional namespace like "cubes". Which means they could have been 
installed directly in site-packages. For OpenERP though, the root 
namespace pollution would be huge because they use no prefix for many 

Best regards,


More information about the Cubicweb mailing list