Re: Request for Review - Nuitka the Python compiler (status update, more questions)

2011-11-16 Thread Kay Hayen



Hello,


I created an ITP for Nuitka here:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=648489


Should I add some link to the debian packages there?


1. The dch is not picking up my email address, unlike reportbug,
kind of annoying.


Solved.


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.


Solved.


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.


Solved. In /usr/share/doc/nuitka/README.pdf now.


I will add a copyright file later.


Solved.


6. The changelog talks of unstable. Is that OK if I am building
against testing ?


Still not clear. I didn't setup a pbuilder yet (the command failed with 
some broken dependencies I last tried). My only build time dependency is 
really python at this time. It makes no sense, because I assume, I am 
somehow to provide a source deb to a sponsor anyway, right?


I also renamed the act alike python binary /usr/bin/Python to 
/usr/bin/nuitka-python as a result of the review.


So that is it, I don't know anymore of things to do. What about a 
manpage, is it considered mandatory?


What should be my next step? :-)

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/4ec378d5.6050...@gmx.de



Re: Request for Review - Nuitka the Python compiler (status update, more questions)

2011-11-16 Thread Nicolas Chauvat
Hello,

On Wed, Nov 16, 2011 at 09:48:21AM +0100, Kay Hayen wrote:
 I also renamed the act alike python binary /usr/bin/Python to
 /usr/bin/nuitka-python as a result of the review.

Nice.

 So that is it, I don't know anymore of things to do. What about a
 manpage, is it considered mandatory?

It is always better to have one. Do you know about rst2man that can
generate a man page from restructuredtext ?

-- 
Nicolas Chauvat

logilab.fr - services en informatique scientifique et gestion de connaissances  


-- 
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/2016094141.ga10...@volans.logilab.fr



Re: Request for Review - Nuitka the Python compiler (status update, more questions)

2011-11-16 Thread Kay Hayen



I wrote:


Anybody has any experience with generating manpages from optparse?


[...]


If anybody does that already, people on this list likely know.


Looking at cything, I found help2man, which is what cython package uses, 
great stuff. Of course, no need to be any Python specific.


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/4ec435a2.4070...@gmx.de



Re: Request for Review - Nuitka the Python compiler (status update, more questions)

2011-11-16 Thread Kay Hayen

Hello,


So that is it, I don't know anymore of things to do. What about a
manpage, is it considered mandatory?


The man page exists and even has an examples section added for the 
typical use cases. I am totally surprised at how easy that was. An 
absolute thumbs up to help2man from here, brilliant.


It's mentioned in the new maintainers guide section about man pages, but 
I was only reading it after I had the manpages created... ;-)


Also, strangely, I have previously removed the sys.path trick for the 
package, because nuitka was a public package (which it shouldn't 
really be, but e.g. mercurial is too.


It no longer is, but I feel it's not because of anything I did. I 
re-instated the LIBDIR trick, because it now is actually useful, and 
am left wondering what happened.


Was there some change that affects Debian Testing and python packaging 
recently? Should I do something about that?


What controls the process of creating links from 
/usr/share/nuitka/nuitka as /usr/lib/python2.7/dist-packages/nuitka?



What should be my next step? :-)


To me the packaging looks finished now. What files do I need to provide 
for potential sponsors? I suppose, what debuild -S gives? I don't get 
that part at all. Of course I would also like to offer a source package 
of nuitka in any case.


Please review the .deb and tell me about it:

http://nuitka.net/releases/nuitka_0.3.15pre3-2_all.deb

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/4ec45a5e.1080...@gmx.de



Re: Request for Review - Nuitka the Python compiler

2011-11-15 Thread Nicolas Chauvat
Hi,

On Sat, Nov 12, 2011 at 10:50:13PM +0100, Jakub Wilk wrote:
 * Paul Boddie p...@boddie.org.uk, 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.

+1

What's wrong with calling nuitka, nuitka ? I do not remember PyPy,
Stackless, Jython, IronPython or any other alternative Python
interpreters trying to install their executable under the name
/usr/bin/python, so why would you want to do it in this case ?

PS: Thank you for working on Nuitka, it looks really interesting.

-- 
Nicolas Chauvat

logilab.fr - services en informatique scientifique et gestion de connaissances  


-- 
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/2015172854.gd3...@volans.logilab.fr



Re: Request for Review - Nuitka the Python compiler

2011-11-15 Thread Kay Hayen


Hello Nicolas,

you wrote:


On Sat, Nov 12, 2011 at 10:50:13PM +0100, Jakub Wilk wrote:

* Paul Boddiep...@boddie.org.uk, 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.


+1

What's wrong with calling nuitka, nuitka ? I do not remember PyPy,
Stackless, Jython, IronPython or any other alternative Python
interpreters trying to install their executable under the name
/usr/bin/python, so why would you want to do it in this case ?


For the record, the package installs /usr/bin/Python which uses 
/usr/bin/python in its #! line.


I just got accustomed to it, you know like when you develop something 
over years, and cannot think of anything else.


The /usr/bin/nuitka binary is not that one, Python is intended to be 
a behave alike python just be faster in a cached way. And nuitka 
shall be the do one of many things binary.


I might remove it from the Debian package, or put it to 
/usr/share/doc/nuitka/examples and then mention it in a README.Debian.


The Python does not accept python alike options anyway yet, it's not 
finished if you wish.


I absolutely don't want Python to block the entry of nuitka to 
Debian proper. Oh collective Debian-Python Brainpower, tell me a good 
name but nuitka for said binary. :-)



PS: Thank you for working on Nuitka, it looks really interesting.


Thanks a lot too.
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/4ec2eeec.6020...@gmx.de



Re: Request for Review - Nuitka the Python compiler

2011-11-15 Thread Nicolas Chauvat
Hello,

On Tue, Nov 15, 2011 at 11:59:56PM +0100, Kay Hayen wrote:

 Oh collective Debian-Python Brainpower, tell me a good name but
 nuitka for said binary. :-)

Reading the doc I understand that Python == Nuitka.py --execute.
Am I correct ?

Maybe Python + nuitka -- nuitka + nuitka-ctl
OrPython + nuitka -- pynuitka + nuitka
OrPython + nuitka -- nuitka + nuitka compiler
OrPython + nuitka -- nython + nuitka
Or something better than the above :)

-- 
Nicolas Chauvat

logilab.fr - services en informatique scientifique et gestion de connaissances  


-- 
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/2015233524.ga27...@volans.logilab.fr



Re: Request for Review - Nuitka the Python compiler

2011-11-15 Thread Kay Hayen


Hello Nicolas,


On Tue, Nov 15, 2011 at 11:59:56PM +0100, Kay Hayen wrote:


Oh collective Debian-Python Brainpower, tell me a good name but
nuitka for said binary. :-)


Reading the doc I understand that Python == Nuitka.py --execute.
Am I correct ?


It's --exe and --exectute, but yes, it executes automatically, and 
the missing feature is to e.g. support -u and other options that the 
normal python has.



Maybe Python + nuitka --  nuitka + nuitka-ctl
OrPython + nuitka --  pynuitka + nuitka
OrPython + nuitka --  nuitka + nuitka compiler
OrPython + nuitka --  nython + nuitka
Or something better than the above :)


I like nython somewhat.

I had previously thought of python.nuitka, but that kind of breaks 
things that expect only version suffixes, I would expect it to not be 
acceptable. If it's not, I would love it.


Hm, what about nuitka-python as a binary name of what is now Python, 
is that OK? It seems the readable variant.


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/4ec2fa7e.9070...@gmx.de



Re: Request for Review - Nuitka the Python compiler

2011-11-15 Thread Thomas Kluyver
On 15 November 2011 23:49, Kay Hayen kayha...@gmx.de wrote:

 Hm, what about nuitka-python as a binary name of what is now Python, is
 that OK? It seems the readable variant.


nuitka-python is what I'd call it, from your description. I'm not actually
a Debian packager, though.

Thomas


Re: Request for Review - Nuitka the Python compiler

2011-11-13 Thread Kay Hayen


Hello Stefano,

Am 12.11.2011 22:16, schrieb Stefano Rivera:

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.


That I noticed, yet it was very helpful for the non-debian cases of 
course. I am currently aiming at compiling (that works) and passing its 
test suite.


That needs more work, e.g. inspect is still hating some parts of 
Nuitka not having bytecode. Look at inspect.getargs occasionally to know 
why I am weeping. It looks at the bytecode doing the unpacking and 
assigning to know the nested parameters of functions...


But of course I also learned a few things from looking at hg and its 
package.



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


I read it now.


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.


Luckily there is no dependency on a version, it just wouldn't work with 
2.5, but I am not sure, it might as well. I originally developed Nuitka 
for CPython 2.5, but then Debian Testing changed to 2.6 and I followed it.


I don't really need or intend to build Nuitka on Wheezy for different 
CPython2 versions. The default will be good enough. For a backport it 
may be 2.6, for Wheezy it can be 2.7, and that's fine.


I really can live with /usr/bin/env python and a single version of 
Python entirely well.


So I think that trick is harmless. Anyway, I will remove it from the 
Debian package. I agree it ought to be unnecessary at best.


So I finally figured out, how to do remove things. I wasn't aware of 
dpkg-source --commit yet at all. Also the inline copy of scons is now 
gone. The copyright is there, etc.


I updated the deb_dist with my current work status:

http://www.nuitka.net/volatile/debian/deb_dist/

The patch is in:

http://www.nuitka.net/volatile/debian/deb_dist/nuitka-0.3.15pre2/debian/patches/

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/4ebf994c.6000...@gmx.de



Re: Request for Review - Nuitka the Python compiler

2011-11-12 Thread Jakub Wilk

* Paul Boddie p...@boddie.org.uk, 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