Request for Review - Nuitka the Python compiler
Hello,
I created an ITP for Nuitka here:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=648489
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.
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.
c) I renamed "Nuitka.py" to a "nuitka" binary. I am keeping the drop-in
replacement as "Python" though.
d) I have used "py2dsc -m "Kay Hayen "
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.
f) The control file I adapted like this:
Source: nuitka
Maintainer: Kay Hayen
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.
--
Then questions I have:
1. The "dch" is not picking up my email address, unlike "reportbug",
kind of annoying.
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.
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.
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.
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/
Yours,
Kay
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4ebe348b.90...@gmx.de
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 "
> 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
> 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 real
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" 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 depe
Re: Request for Review - Nuitka the Python compiler
Hi Kay (2011.11.12_23:01:43_+0200) > 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. I disabled that in mercurial in Debian. It caused a rather nasty bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=620087 first noticed in Ubuntu: https://bugs.launchpad.net/ubuntu/+source/mercurial/+bug/745250 The way we handle multiple python versions in Debian allows for .so and .py files to differ between python versions (although .py files differing is ugly and should be avoided). However, we cannot deal with differences like that in scripts in /usr/bin. There's only one of those, shared between all the python versions, so if you put things in it that depend on a particular python version, things get ugly. SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 465 6908 C: +27 72 419 8559 UCT: x3127 -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2012211630.gi9...@bach.rivera.co.za
Re: Request for Review - Nuitka the Python compiler
* Paul Boddie , 2011-11-12, 15:08:
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",
Agreed, this is bad idea.
If Nuitka aims to be a Python alternative, shouldn't it use the
alternatives mechanism in Debian?
We don't use alternatives for Python interpreters, for good reasons.
I didn't know there was an --install-layout option to setup.py, but I
haven't been following distutils so closely of late.
--install-layout is a Debian-specific option.
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
Why?
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 can assure you that simplicity of your debian/rules has nothing to do
with dh_python (or dh_python2, which you maybe meant) development.
I have an override in the rules file for the man page:
override_dh_auto_clean:
rm -f debian/shedskin.1
dh_auto_clean
dh_clean reads filenames from debian/clean. You could add
"debian/shedskin.1" to the file, and then get rid of this override.
--
Jakub Wilk
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2012215013.ga4...@jwilk.net
Re: Request for Review - Nuitka the Python compiler
On Saturday 12 November 2011 22:50:13 Jakub Wilk wrote: > * Paul Boddie , 2011-11-12, 15:08: > >If Nuitka aims to be a Python alternative, shouldn't it use the > >alternatives mechanism in Debian? > > We don't use alternatives for Python interpreters, for good reasons. OK. I know of the alternatives system and have seen it used for stuff like Java, so I thought it might be applicable to Python. > >I didn't know there was an --install-layout option to setup.py, but I > >haven't been following distutils so closely of late. > > --install-layout is a Debian-specific option. Interesting. [...] > >I was told to drop X-Python-Version > > Why? I may have been using XS-Python-Version, so I guess I'm a bit confused about this. > >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 can assure you that simplicity of your debian/rules has nothing to do > with dh_python (or dh_python2, which you maybe meant) development. Well, my point was just that something - debhelper, perhaps? - made the rules file a lot smaller and with less boilerplate, which is useful if you're maintaining a lot of packages. I was using pycentral before, and there's a huge difference between then and now. > >I have an override in the rules file for the man page: > > > >override_dh_auto_clean: > >rm -f debian/shedskin.1 > >dh_auto_clean > > dh_clean reads filenames from debian/clean. You could add > "debian/shedskin.1" to the file, and then get rid of this override. OK, I've done this now. I can't see the debian/clean file in the New Maintainers' Guide, but I guess it's documented somewhere. Paul -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20122354.12071.p...@boddie.org.uk
