[Cubicweb] Move sources to a sub-directory

Christophe de Vienne christophe at unlish.com
Fri Aug 29 13:22:08 CEST 2014

Le 29/08/2014 12:55, Aurélien Campéas a écrit :
> On 29/08/2014 12:47, Christophe de Vienne wrote:
> [...]
>> When I work with pyramid, using virtualenv is easy : pip install pyramid
>> and I am ready to go.
>> Not using it is complicated, see the in-progress confman configuration
>> of Aurélien to get an idea : it forces you to take some (way too long)
>> time to properly setup your pythonpath.
> That's an unfortunate consequence of the new "community standard"
> package layout ...

This layout is not "that" new. I have seen it around for at least 10 years.
And it becoming a standard is not from yesterday either.

>> Currently I use a hybrid of virtualenv/setup.py develop + the
>> grshell-cubicweb to work on pyramid_cubicweb. And it makes things more
>> difficult than needed.
>> For example, I would like this sequence to be enough to start working on
>> pyramid_cubicweb and cubicweb sources (which is my current need):
>>      hg clone xxx/cubicweb
>>      hg clone xxx/pyramid_cubicweb
>>      mkvirtualenv devenv
>>      pip install -e xxx/cubicweb
>>      pip install -e xxx/pyramid_cubicweb
>> If, later, I have to patch pyramid itself, or yams :
>>      hg clone xxx/yams
>>      pip install -e yams
>> Easy to do for anybody, especially new comers. And even more easy
>> because most python developers works like this today.
> Just nitpickingly, let's not confuse "easy" with "community aproved" :)

easy is what I can get a new comer on the project to do in 5 minutes and 
be ready to code.

Today, with the way CW works, if we need to work with any package that 
is not part of the cw ecosystem and is not packaged with the right 
version in the distribution we use, there is no "easy" solution that 
does not involve adhoc tools or extensive documentation.

>> That said, all the packages I know, except for the cubicweb ecosystem,
>> works nicely with virtualenv and setup.py develop. Keeping cubicweb
>> pip-unfriendly is definitely not the right thing to do.
> Unfortunately, agreed.

The de-facto "standard" way is not that bad, really. I am pretty 
confident that you will not loose much with it. You may even get to like 
it eventually :-)


More information about the Cubicweb mailing list