Re: Request for Review - Nuitka the Python compiler
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.
> 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.
> 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.
> 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?
> 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.
> f) The control file I adapted like this:
>
> Source: nuitka
> Maintainer: Kay Hayen <kayhayen@gmx.de>
> Section: python
> Priority: optional
> Build-Depends: python (>= 2.6.6-3), debhelper (>= 7.4.3)
> Standards-Version: 3.9.1
>
> Package: nuitka
> Architecture: all
> Depends: ${misc:Depends}, ${python:Depends}, g++-4.6 (>= 4.6.1), scons
> (>=2.1.0-1)
> Description: Python compiler with full language support and CPython compa
> X-Python-Version: >= 2.6
>
> The general goal would be to make it back portable, that is why I am
> using Python 2.6 as my upstream required minimum. I hope control is the
> right spot, the tutorial didn't make that so clear.
>
> 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.
> ----------
>
> Then questions I have:
>
> 1. The "dch" is not picking up my email address, unlike "reportbug",
> kind of annoying.
Does it not use the DEBEMAIL environment variable?
> 2. I would like to remove the "inline_copy" directory with a patched
> scons from the package, as it's not necessary with Debian when having
> the dependency.
>
> 3. My documentation is ".rst", so I guess, i should build-depend on
> docutils, and so something, but what? Maybe that's really a distutils
> question, but I wonder where to put the resulting pdf.
I have python-docutils in my Build-Depends since Shedskin generates a man page
from a .rst file. I guess the PDF would live in /usr/share/doc/nuitka, and
you could probably mention it in debian/docs.
> 4. My workflow now would be to start from py2dsc over and over again,
> and to script the replacement of the debian control files. It seems
> rather pointless to keep more than those files:
>
> debian/compat
> debian/changelog
> debian/rules
> debian/control
> debian/links
> debian/source
> debian/source/format
>
> I will add a copyright file later.
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
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.
> 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/
> 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.
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.
Paul
Reply to: