<meta content="text/html; charset=windows-1252"
<body text="#000000" bgcolor="#FFFFFF">
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.<br>
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.<br>
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
Using subdirectory would ease the work of most developers outside
Logilab who wants to try and adopt cubicweb.<br>
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.<br>
That said, outside of the "setup.py develop" reason for having a
subdirectory, here are a few additional good reasons for doing it:<br>
- "sdist", which has been around for a while.<br>
<blockquote>If you "setup.py sdist" cubicweb today, you get a
.tar.gz which is the official distribution of a python module.<br>
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'.<br>
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
- 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:
<a class="moz-txt-link-freetext" href="http://legacy.python.org/dev/peps/pep-0376/">http://legacy.python.org/dev/peps/pep-0376/</a>, we cannot ignore it.
The idea is that the whole package, and only the package, is in this
- Make useless something like this :
<a class="moz-txt-link-freetext" href="http://hg.logilab.org/review/cubes/blog/file/9d38aa2bf1c9/__pkginfo__.py#l51">http://hg.logilab.org/review/cubes/blog/file/9d38aa2bf1c9/__pkginfo__.py#l51</a>.
Such lines made me loose time because I did not understand why my
package was only partially installed.<br>
- 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.<br>
- 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
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".<br>
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.<br>
<div class="moz-cite-prefix">Le 31/08/2014 22:43, Nicolas Chauvat a
On Fri, Aug 29, 2014 at 01:22:08PM +0200, Christophe de Vienne wrote:
<pre wrap="">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.
<pre wrap="">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
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
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?