Introduction
Dear Python Team, As I have just joined (thank you Piotr!) the python-apps project on Alioth, I would like to introduce myself. I am a package maintainer since 2010, Debian Maintainer and on my way to become a Debian Developer. I am currently maintaining 5 packages, 2 of which are Python-based packages: autojump and itstool. I consider myself as quite perfectionist, which is a reason why I like the high quality standards of the Debian projects, for instance the requirement to have a manpage for every program. I am also rather enthusiast with modern packaging standards such as source format 3.0 (quilt), DEP-3, DEP-5 and catchall-style dh7 rules. I also have a tendency to act and sometimes make mistakes quickly, which is certainly a way to learn but can be annoying, particularly when there are users involved… And finally, I am fond of Git, which means I will have to adapt myself back to Subversion¹. :-) So, I have joined python-apps in order to include at least one of my packages, itstool, into it. The practical reason for that is that I need sponsoring, and that it seems to be easier this way, but I guess there will be other benefits too; I must also say that I never worked in a Debian team before. Cheers, -- ,--. : /` ) Tanguy Ortolo xmpp:tan...@ortolo.eu irc://irc.oftc.net/Elessar | `-'Debian Maintainer \_ ¹ Yes, I know git-svn, but it is still quite different from pure Git, and I am not sure this can be easily adapted to the packaging workflows. signature.asc Description: Digital signature
Re: Introduction
2011/10/12 Tanguy Ortolo tanguy+deb...@ortolo.eu: As I have just joined (thank you Piotr!) the python-apps project on Alioth, I would like to introduce myself. Welcome! I am a package maintainer since 2010, Debian Maintainer and on my way to become a Debian Developer. I am currently maintaining 5 packages, 2 of which are Python-based packages: autojump and itstool. So, I have joined python-apps in order to include at least one of my packages, itstool, into it. The practical reason for that is that I need sponsoring, and that it seems to be easier this way, but I guess there will be other benefits too; I must also say that I never worked in a Debian team before. itstool is not Python. Perhaps itstool could be part of the Debian GNOME team as the upstream developer (Shaun) is a GNOME developer and I think it's so far only used by GNOME-ish apps. Jeremy Bicha -- 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/CAAajCMa2XA6an4mm=wiKDEPw9adaiEg_aW=wrcj3q+6tm0o...@mail.gmail.com
Re: Introduction
Jeremy Bicha, 2011-10-12 10:48 UTC-0400: itstool is not Python. Perhaps itstool could be part of the Debian GNOME team as the upstream developer (Shaun) is a GNOME developer and I think it's so far only used by GNOME-ish apps. For now, it is only used by one package of mine, in fact. :-) But that may change and it is a generic tool that could be used by people outside of GNOME. But although it is not part of Python, it is written in Python and I think this is the point of PAPT, am I mistaking? -- ,--. : /` ) Tanguy Ortolo xmpp:tan...@ortolo.eu irc://irc.oftc.net/Elessar | `-'Debian Maintainer \_ signature.asc Description: Digital signature
Re: Introduction
2011/10/12 Tanguy Ortolo tanguy+deb...@ortolo.eu: Jeremy Bicha, 2011-10-12 10:48 UTC-0400: itstool is not Python. Perhaps itstool could be part of the Debian GNOME team as the upstream developer (Shaun) is a GNOME developer and I think it's so far only used by GNOME-ish apps. For now, it is only used by one package of mine, in fact. :-) But that may change and it is a generic tool that could be used by people outside of GNOME. But although it is not part of Python, it is written in Python and I think this is the point of PAPT, am I mistaking? itstool is also a dependency of yelp-tools which is a dependency of gnome-user-docs. While there's nothing preventing it to be used by any app, I think that it will be picked up by GNOME faster. The only Python script I found in itstool was one to run the testcases (which also include po and pot files); everything else is XML. Anyway, I'm definitely not very active with Debian Python so it's not my place to say whether it should or should not be in PAPT. Jeremy Bicha -- 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/caaajcmyg5ow+vq4avkzatfgt7-q5kwwurs0vn5guushbutj...@mail.gmail.com
Re: Introduction
Jeremy Bicha, 2011-10-12 11:32 UTC-0400: itstool is also a dependency of yelp-tools which is a dependency of gnome-user-docs. While there's nothing preventing it to be used by any app, I think that it will be picked up by GNOME faster. I did not see that, and it is nice to see that my package is useful! So indeed, it may be more relevant to do that within the GNOME team, except that I have absolutely no interest in GNOME itself, whereas I do for Python. Any advice? The only Python script I found in itstool was one to run the testcases (which also include po and pot files); everything else is XML. How did you come to that conclusion? The main script, itstool itself, is written in Python! My package does not depend on python for no reason… -- ,--. : /` ) Tanguy Ortolo xmpp:tan...@ortolo.eu irc://irc.oftc.net/Elessar | `-'Debian Maintainer \_ signature.asc Description: Digital signature
Re: Introduction
2011/10/12 Tanguy Ortolo tanguy+deb...@ortolo.eu: How did you come to that conclusion? The main script, itstool itself, is written in Python! My package does not depend on python for no reason… Ah, I see. I was looking for a .py extension. Sorry about that. Jeremy -- 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/CAAajCMbZJeTdjoihU-kQ=zvbviejo8jozxem+hedfs1ugag...@mail.gmail.com
Re: Introduction
2011/10/12 Tanguy Ortolo tanguy+deb...@ortolo.eu: How did you come to that conclusion? The main script, itstool itself, is written in Python! My package does not depend on python for no reason… Ah, I see. I was looking for a .py extension. My apologies. Jeremy -- 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/caaajcmyx6ne+vtosyo9usj2j3slki1aeqgvbx44ycuh+bq9...@mail.gmail.com
Re: Request for packaging - Nuitka the Python Compiler
Hello Jakub, http://www.nuitka.net/blog/nuitka-a-python-compiler/what-is-nuitka/ How is it different/better than pure-Python[0] mode of Cython? It's more compatible to CPython than anything that exists. Nuitka passes practically 100% of the test suite. Currently I don't have support for threading, and that's it. Frame stack works perfect in branch already. Nuitka is a project not about a hybrid language, and not about C types, and it's intended for whole programs acceleration. That's probably differences that currently matter. It's design is cleaner, it uses the CPython parser to parse Python, it uses Scons to build the generated code, etc. Cython is trying to be more Python compatibility recently, but Nuitka already had full language coverage, before Cython started with generators. Now they have it. But there is still unimportant things, not supported. I believe Cython is currently the best choice available for something productive, but Nuitka has a cleaner plan (only Python semantics matter) and I believe a quicker road to success, and has already uses. Ultimately, I agree with Dr. Stefan Behnel, one of the lead developers of Cython, that the projects are coming from different ends, but reach out to similar goals. I gave my reasons on recent PyCON DE. But it boils down to willingness to move and different goals. Stefan agrees with me that Nuitka has different enough goals, or so I understood. To give an example, parameter errors. The error messages of Nuitka are identical to CPython and that's the test. The error message of Cython are not identical and arguably not better. The generated code may be or or less faster. To me, the only correct solution is the one that 100% imitates CPython and even avoids improvements to CPython. To Stefan the faster solution is an acceptable compromise. With this approach, a 100% compatibility cannot be achieved, which also means that you have to have your own tests. Cython needs to have a lot of efforts, because it has data driven testing that describes the non-CPython behaviour of Cython. I can just compare CPython and Nuitka and every difference is a bug. 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/4e9615bd.4060...@gmx.de
Re: Request for packaging - Nuitka the Python Compiler
Hello Yaroslav, Since everyone seems to be busy and since you are an experienced Debian user -- would you consider trying to package it yourself? it is really not a rocket science I must admit, I am a bit scared at that perspective. Creating the compiler itself is a huge task. Adding to that worries me. If nobody wants to package it now, I will just wait until somebody wants to. The easier road for me might be to make Nuitka attractive enough then. Currently I am just trying to be a good upstream. I have that stable branch in master, with no less than 5 hotfixes. Every bug I encounter gets fixes on a hotfix branch that is automatically pushed to as well as to development branch. http://www.nuitka.net/gitweb/?p=Nuitka.git;a=summary That's quicker and better than many other projects, who make bug fix releases only as an afterthought, of continued development. I will sustain that. And I didn't consider packaging practical without that. You see, new Nuitka releases are not supposed to add major new features now, only increased acceleration. Support for Python3 probably being the exception there should be. But normally there won't be features people want, except for even more speed. But correctness is something I take absolutely serious. If Nuitka is not correct or not compatible, that will make it remain unused. That's why I went 100% there, before I start to make Nuitka seriously fast. and file an ITP (or at least RFP if not planing to work on packaging) for it. Will file an RFP then. 1 tiny comment: Nuitka.py script better looses its suffix (.py) if you are planing to have it installed under /usr/bin (and I would even suggest to make it all lower-cased -- nuitka -- although not strictly enforced but advised: imagine if all the tools g++, Python, cython, LDD, Make had inconsistent casing) That's the kind of things I am looking for. And another thing that worries me. In the Scons file, I have things like this to find the C++ sources to compile: nuitka_src = os.environ.get( NUITKA_CPP, ./src/) ... nuitka_include = os.environ[ NUITKA_INCLUDE ] or to start Scons from Nuitka with the general scons file: scons_file : os.environ[ NUITKA_SCONS ] + /SingleExe.scons, The main reason I want to see it packaged now, is to learn about things that make Nuitka potentially a bad upstream. There is probably more, and I would appreciate it. Anyone who would give it a critical review would do me and the project already a huge favor that will only reward later on. 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/4e96191a.40...@gmx.de
Re: Request for packaging - Nuitka the Python Compiler
On Thu, Oct 13, 2011 at 6:47 AM, Kay Hayen wrote: Currently I am just trying to be a good upstream. On that topic, we have a bunch of good links and some Debian-specific information about how to be a good upstream here: http://wiki.debian.org/UpstreamGuide I would personally add don't use SCons that, simply because of my experience with an upstream who started using it; I had to re-implement a bunch of autotools features, starting with $DESTDIR. Not sure if it has improved since then. -- bye, pabs http://wiki.debian.org/PaulWise -- 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/caktje6hrsmf8-0c3dukcn4ofmap9odhbsksq0gdw9pdc0w_...@mail.gmail.com
