[Cubicweb] CWEP 0004 - Cubes as distributions
Christophe de Vienne
christophe at unlish.com
Thu Oct 23 10:20:57 CEST 2014
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
>> - If modules are imported from one cube to another, multiple values in
>> CUBES_PATH is not possible, because the root "cubes" directory is
>> to be in the PYTHONPATH.
>> This particular issue makes it difficult, if not impossible, to
>> cubes system-wide (or in a virtualenv) and work on cubes in a work
> 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 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
> 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
More information about the Cubicweb