[Cubicweb] CWEP 0004 - Cubes as distributions

Denis Laxalde denis.laxalde at logilab.fr
Thu Oct 23 11:04:04 CEST 2014


Christophe de Vienne a écrit :
>> 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).

Not cluttering site-packages is arguably an advantage.

> 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).

You mean a directory without an __init__.py?

>> 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).

Could you list the options you have in mind about the installation 
layout in the CWEP text? From what I understood, there'd be:

- have a directory where all cubes would live in (without __init__.py?)
- have a namespace package
- have each cube installed as cubicweb_<cubename> in dist-packages (the 
pyramid way)


>> 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).

This is probably a bug. I guess there is no "perfect" workflow anyhow...

>>> -   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
> modules.

So, if I understand correctly, we could keep the cubes "private" but 
should remove the "cubes" namespace and add the "cubes" directory to 
PYTHONPATH.


-- 
Denis Laxalde
Logilab         http://www.logilab.fr



More information about the Cubicweb mailing list