[Cubicweb] Move sources to a sub-directory

Christophe de Vienne christophe at unlish.com
Mon Sep 1 00:56:26 CEST 2014


Hi Nicolas,

I understand your "Python should not build its own platform and 
packaging system", but I think it is a lost battle, whatever the 
reasons. We need to be pragmatic here.

The question is how do we work from the sources, because once packaged 
in a distribution and installed in the system (or a virtualenv), the 
result is strictly the same.

Using only the PYTHONPATH remains possible when moving the sources to a 
subdirectory. It is more work because several entries are necessary 
where one was enough, but it is possible. You could also use symlinks 
(easy with the grshells). But you do not have to adopt virtualenv.

Using subdirectory would ease the work of most developers outside 
Logilab who wants to try and adopt cubicweb.

Not using it almost imposes to use confman or guestrespo in situations 
were it should not be needed. At Unlish, I would prefer not be need 
confman/guestrepo because most of the time we only need to work on the 
unlish cube.

That said, outside of the "setup.py develop" reason for having a 
subdirectory, here are a few additional good reasons for doing it:

- "sdist", which has been around for a while.

    If you "setup.py sdist" cubicweb today, you get a .tar.gz which is
    the official distribution of a python module.
    The content of this tar.gz is a directory containing most of what
    that is in the cubicweb repository. But its name is not 'cubicweb',
    it is 'cubiweb-VERSION'.
    If we get the source distribution of cubicweb, we will have to
    rename this directory if we want to use it directly. And we would
    have to move this directory somewhere we can add to PYTHONPATH
    without side-effects.

- Keep the sources separated from docs, the setup.py, the tests, some 
dev tools, the  the .dist-info (.egg-info) - Note that .dist-info is 
part of python: http://legacy.python.org/dev/peps/pep-0376/, we cannot 
ignore it. The idea is that the whole package, and only the package, is 
in this subdirectory.

- Make useless something like this : 
http://hg.logilab.org/review/cubes/blog/file/9d38aa2bf1c9/__pkginfo__.py#l51. 
Such lines made me loose time because I did not understand why my 
package was only partially installed.

- Be able to run the project without touching the PYTHONPATH nor running 
"develop" if the cwd is the root directory. This is true for project 
with little dependency but still.

- Allow the root directory of a package to be added the PYTHONPATH. It 
may sound weird but when coding, I expect all the packages involved in 
the current project to be added one-by-one to the PYTHONPATH.


As a conclusion, I would say that the question is not if the layout will 
be changed, but when. And even if I can understand your concern about 
all this packaging issue (which is definitely getting better, or less 
crappy if you like, since last year), I am afraid you are right when you 
say "outnumbered".


Best regards,

Christophe

PS: Using subdirectory for the cubes is a slightly different matter for 
as long as their code is not installed in site-packages. We should let 
them like this in a first step.

Le 31/08/2014 22:43, Nicolas Chauvat a écrit :
> Hi,
>
> On Fri, Aug 29, 2014 at 01:22:08PM +0200, Christophe de Vienne wrote:
>> 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.
> It was new ten years ago, when Logilab had already been in business
> for 5 years and I had been using Python for 8 years. I still think
> this new idea is a bad idea. And I still think every language building
> its own platform and packaging system is a bad idea.
>
> But I now what "outnumbered" means.
>
>> 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 :-)
> My opinion is that these tools where created just because people
> decided to add a sub-directory as was being done with sources that
> needed to be compiled. Remove the sub-directory and you can drop all
> the tools and make the things simpler and reduce the chances of
> failure.
>
> We had a sub-directory at some point around 2001/2002 to separate code
> from other files and removed it from our projects because plain
> PYTHONPATH was simpler and easier to set things up (no extra command
> to type, no extra symlinks to make and keep current, no extra
> documentation).
>
> Could we change things such that the "I like it more complex"
> community can have it their way and I/we can continue to use
> PYTHONPATH and ignore the virtualenv/develop/setup and other steps
> that remind me of using configure/make and make me feel I moved away
> from the Debian platform to enter the Python-only-land?
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cubicweb.org/pipermail/cubicweb/attachments/20140901/81374875/attachment-0005.html>


More information about the Cubicweb mailing list