Re: Request for Review - Nuitka the Python compiler
Hello Paul,
Am 12.11.2011 15:08, schrieb Paul Boddie:
On Saturday 12 November 2011 09:55:39 Kay Hayen wrote:
I created an ITP for Nuitka here:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=648489
I've been following Nuitka, and I think it's great to see how it has
progressed over time. Since I've been trying to package Shedskin for Debian,
it will be interesting to see how you have approached the packaging exercise.
Thanks for the kind words.
I have followed your advice in as so far received, and made the
following things:
a) First of all, I added "setup.py" and distutils stuff to Nuitka,
something I had never done before.
For Python packages, I think the benefit of having setup.py outweighs the
sometimes bizarre behaviour of distutils.
Well, I clearly don't regret it now, but it is so not documented how to
get anything done, it really hurts. But apart from that it has only lead
to cleaner structures, and forced me to find ways to avoid environment
variables, that I had previously used a lot.
For PYTHONPATH, the hardest part, I now use this code here:
libdir = '@LIBDIR@'
# Two cases:
if libdir != '@' 'LIBDIR' '@':
# Changed by our distutils hook, then use the given path.
if not os.path.isabs( libdir ):
libdir = os.path.join( os.path.dirname( os.path.realpath(
__file__ ) ), libdir )
libdir = os.path.abspath( libdir )
sys.path.insert( 0, libdir )
else:
# Unchanged, running from checkout, use the parent directory, the
nuitka package ought be there.
sys.path.insert( 0, os.path.join( os.path.dirname( __file__ ), ".." ) )
More or less stolen from "/usr/bin/hg" which does something similar. I
have hooked distutils to modify the scripts and replace @LIBDIR@ for the
binary distributions.
b) To facilitate that, I have moved the C++ and Assembler codes to new
packages and declared them as package data. That were huge changes, but
for the better I guess.
For libraries used only by Shedskin I used /usr/share/shedskin, necessitating
patches to the upstream setup.py script.
Luckily Nuitka has no such libraries. You reminded me to "recommend"
"python-lxml", which is an optional dependency, used to dump XML out of
note trees. And of course, "python-qt4" which is used to inspect the
tree if the user wants. Both of which are not mandated in imports to
succeed. Should it be "suggests" then?
Nuitka is really small dependency wise if I dare say so.
c) I renamed "Nuitka.py" to a "nuitka" binary. I am keeping the drop-in
replacement as "Python" though.
I don't think it's wise to call it "Python", even though virtually everyone
using Debian uses case-sensitive filesystems and knows the difference
between "python" and "Python". If Nuitka aims to be a Python alternative,
shouldn't it use the alternatives mechanism in Debian?
Well, Nuitka itself needs "/usr/bin/python" to boot. It can then compile
itself, but I don't think of it in the alternatives system way, it's not
like that.
Right now I like how I just change:
python tests/basics/Functions.py
->
Python tests/basics/Functions.py
I found no really good name to convey the job it does. Using upper case
means it's quite invisible until you learn about it. I could imagine
that it won't be accepted though.
d) I have used "py2dsc -m "Kay Hayen<kayhayen@gmx.de>"
Nuitka-0.3.15pre2.tar.gz" on what the dist directory gives me. I have
then edited, the debian directory according to the tutorial.
e) I have resolved the collision of the binary and package name not by
renaming it, I wouldn't know when and where to do it, but by puting it
into "bin", like this:
override_dh_auto_install:
python setup.py install --root=debian/nuitka --install-layout=deb
--install-lib=/usr/share/nuitka --install-scripts=/usr/share/nuitka/bin
override_dh_auto_build:
and have links like this:
/usr/share/nuitka/bin/Python /usr/bin/Python
/usr/share/nuitka/bin/nuitka /usr/bin/nuitka
which appears to work fine.
I wonder if there's any benefit to putting things in /usr/share/nuitka/bin,
but I suppose you're working within the limitations of distutils. I didn't
know there was an --install-layout option to setup.py, but I haven't been
following distutils so closely of late.
That option I have from the tutorial. The tutorial suggests to rename
"nuitka" to something different if the package name and the binary name
are the same, and then resolve this through the link to the original
name, but I don't like it at all.
Plus I don't know _when_ to rename it. I have no clue how to patch the
Nuitka source yet. Of course I am in a good position to not want to do
it much, being upstream and packager in one person.
For build depends I am not so sure.
I was told to drop X-Python-Version and to put the compilers and build tools
into the Recommends field.
Hm, the g++-4.6 is a real run time dependency I have, as is scons, the
package is useless without them. And you need a CPython >= 2.6, which I
guess, should be a dependency too. I didn't get X-Python-Version and its
usage so far.
1. The "dch" is not picking up my email address, unlike "reportbug",
kind of annoying.
Does it not use the DEBEMAIL environment variable?
Thanks, that works. I now found it in the man page too. I had looked,
but obviously too cursory, sorry.
I've always worked with the debian directory's files directly, and with recent
dh_python developments, the tricky parts like the rules file becomes almost
trivial; I have an override in the rules file for the man page:
override_dh_auto_clean:
rm -f debian/shedskin.1
dh_auto_clean
override_dh_auto_build:
rst2man doc/shedskin.rst debian/shedskin.1
dh_auto_build
I tried to use and then it didn't work, rst2pdf was doing its thing, but
debian/doc apparently not. And then I realized, that it ought to be done
by setup.py or should it not? If just - as normal I guess - have no clue
how to add it there.
Seems from my googling, that everybody builds it before setup.py is run,
which I kind of dislike. I don't want to have generated documents in the
source git repository.
The crucial realisation for me was that the changelog and control files really
drive the rest of the packaging process. It may seem odd that the changelog
has such an important role, but it dictates the version number of the package
and whether it is a native or non-native package.
It's good, because it makes sure that the changelog is updated.
5. Should I now setup my own repository, or is it realistic to get it
into Debian proper, or is there a lot missing now. The copyright should
be easy for me, but yeah, I have no clue really.
The package is going to see some flux still, I guess. The "Python" e.g.
should accept options like python does. On the other hand, I have no
clue how to provide an apt repository these days, the HOWTOs I found are
all obsolete, and "repropro" package seems to be more about mirroring.
I've been uploading packages to http://mentors.debian.net/ and if you want
some kind of quick guide to deploying repositories, take a look at...
http://packages.boddie.org.uk/
That's a good one. I will try to follow that and let you know how it goes.
My package has to be built for "Wheezy", because with "Squeeze" the
runtime dependency g++-4-6 apparently cannot be satisfied from the
Debian backports, I didn't find it at least not for ARM and not in the
package search.
Building Nuitka against "unstable" is rather pointless, as there aren't
going to be any binaries inside. At least not until I make the debian
package contain the compiled version of Nuitka as well. But then it
won't matter much, if I use the pbuilder I guess.
6. The changelog talks of "unstable". Is that OK if I am building
against "testing" ?
What I have currently, you can browse it at:
http://www.nuitka.net/volatile/debian/deb_dist/
I was told to build against unstable. For me, this means having a User Mode
Linux installation running Debian stable (since I can debootstrap that), and
then having a pbuilder instance for unstable inside that (since unstable
can't be run on my host system's kernel). Yes, I'm running an old
distribution, so it means quite a bit more work.
Before Nuitka can be considered for upload, I expect there to be quite
some more work needed. Some of which I now have.
I'd be interested to share notes with you. It would be nice to see some of
these Python-related tools get more exposure in Debian.
Definitely true.
Yours,
Kay
Reply to: