Re: How does team maintenace of python module works?
On Thu, 2013-02-21 at 12:08 +0800, Chow Loong Jin wrote: On 21/02/2013 11:58, Scott Kitterman wrote: I'm all for easy. I have yet to see a full source (regardless of VCS) or git workflow that I didn't find more complex and harder to remember/do correctly than what we have now. I really don't care about what the new hotness is. It actually needs to be better and not just cooler. For me, a lot of better is simpler. Update package: - edit - debcommit -a - git buildpackage (--git-builder=sbuild -d $distribution) Tagging: - git buildpackage --git-tag (or --git-tag-only if you've already built) Import new orig tarball: - git import-orig $tarball Cloning repository: - gbp-clone git://git.debian.org/….git Updating repository: - gbp-pull Looks simple enough to me. How much simpler do you want it? Why not document the workflow (or any other workflow in Debian for that matter) by means of an executable Makefile with targets like: help: egrep ^#DOC Makefile template: # Build a script which the user will edit replacing # keywords by package name etc. # The script will invoke this Makefile with the right # values in environmental variables update: debcommit -a ... git buildpackage ... tag: git buildpackage --git-tag import: # Set the $tarball environment variable git import-orig $tarball etc. etc. --- Omer -- Make love not war. More cleavage, less carnage. My own blog is at http://www.zak.co.il/tddpirate/ My opinions, as expressed in this E-mail message, are mine alone. They do not represent the official policy of any organization with which I may be affiliated in any way. WARNING TO SPAMMERS: at http://www.zak.co.il/spamwarning.html -- 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/1361428448.20304.186.camel@c4
Re: GUI tool for packaging
On Fri, 2012-11-09 at 13:19 +, Thomas Kluyver wrote: In my opinion, the best way to do that is to build a GUI that holds the user's hand through the process of packaging, showing them the options available. It should be particularly useful for occasional packagers who don't want to remember a load of commands and options. [... snipped ...] So, I'd like to know: - Do you think this is worth spending time on? Bear in mind it's primarily aimed at new occasional packagers, not experts who already know the tools. - Is there already anything like this? - Would you be interested in helping to develop it? Of course, this should be useful for any packages, not just Python-based ones. But I thought I'd float the idea here first, to get some feedback before I take it any further. I think it is an excellent idea. There is a general problem of discovering rarely-used commands and/or options and using them to do something one does not need to do frequently. Existing documentation and help information are geared toward novices who will become experts, who make frequent use of the software. Such people eventually remember all the options of the software. What is missing is help for experts, who learned the software sometime ago but use it rarely and therefore with time they forget the minutiae and the details of using the software's options. --- Omer -- Your liberty to swing your fist ends just where my nose begins. Your freedom of expression ends where my freedom of expression begins. Your freedom of religion ends where my rights for equality and accessibility begin. My own blog is at http://www.zak.co.il/tddpirate/ My opinions, as expressed in this E-mail message, are mine alone. They do not represent the official policy of any organization with which I may be affiliated in any way. WARNING TO SPAMMERS: at http://www.zak.co.il/spamwarning.html -- 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/1352468465.31981.74.camel@c4
[OFFTOPIC] Re: Re: Future of python2.6 in Debian
Is the empty message meant to say that python2.6 has no future in Debian? :-) On Sun, 2012-06-17 at 08:35 +0200, Jacques Brassé wrote: -- $ python type(type(type)) type 'type' My own blog is at http://www.zak.co.il/tddpirate/ My opinions, as expressed in this E-mail message, are mine alone. They do not represent the official policy of any organization with which I may be affiliated in any way. WARNING TO SPAMMERS: at http://www.zak.co.il/spamwarning.html -- 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/1339916560.5093.3.camel@c4
Re: Discuss Python plans for (early) wheezy cycle
On Thu, 2011-01-20 at 17:47 -0500, Barry Warsaw wrote: On Jan 20, 2011, at 11:16 PM, Piotr Ożarowski wrote: [Barry Warsaw, 2011-01-20] If I may make a radical suggestion though: what do you think about making Python 3 the default for Wheezy? over my dead body ;-P Okay, then Wheezy+1 :) How about supporting both python (default being Python 2.7) and python3 (default being Python 3.x, x=2 in Wheezy?) forever as two separate languages? New applications will be encouraged to be developed in python3. Legacy applications will be migrated to Python 2.7. I suppose Perl will do a similar thing with Perl 5.x and Perl 6.x once Perl 6 is ready. --- Omer -- $ python type(type(type)) type 'type' My own blog is at http://www.zak.co.il/tddpirate/ My opinions, as expressed in this E-mail message, are mine alone. They do not represent the official policy of any organization with which I may be affiliated in any way. WARNING TO SPAMMERS: at http://www.zak.co.il/spamwarning.html -- 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/1295563939.6619.245.ca...@c4.home.zak.co.il
Re: Is it worth back porting PEP 3147 to Python 3.2?
On Tue, 2010-04-20 at 15:39 -0400, Barry Warsaw wrote: On Apr 20, 2010, at 06:50 AM, Omer Zak wrote: My take of the situation: Yes, please backport PEP 3147 to at least Python 2.7. The rationale: we'll need to support both Python 2.x and Python 3.x for several years, and it will be nice if the same library package can be made to support both 2.x and 3.x. It would also be nice to define a way to specify that a tree of Python 2.7 scripts are to be compiled into Python 3.x bytecode, by specifying that the compilation process has first to run 2to3 (http://docs.python.org/py3k/library/2to3.html#to3-reference) on the Python scripts and actually compile the 2to3's output. If we can come up with a reasonable way to make that work, then I'd be in favor of back porting the PEP to Python 2.x. Julian Andres Klode suggested a way to do so. DISCLAIMER: I didn't verify that it actually works. On Tue, 2010-04-20 at 07:47 +0200, Julian Andres Klode wrote: Use build_py_2to3 from distutils.command.build_py, for example: if sys.version_info[0] == 3: from distutils.command.build_py import build_py_2to3 cmdclass['build_py'] = build_py_2to3 -- $ python type(type(type)) type 'type' My own blog is at http://www.zak.co.il/tddpirate/ My opinions, as expressed in this E-mail message, are mine alone. They do not represent the official policy of any organization with which I may be affiliated in any way. WARNING TO SPAMMERS: at http://www.zak.co.il/spamwarning.html -- 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/1271796600.5062.24.ca...@c2.home.zak.co.il
Re: Is it worth back porting PEP 3147 to Python 3.2?
My take of the situation: Yes, please backport PEP 3147 to at least Python 2.7. The rationale: we'll need to support both Python 2.x and Python 3.x for several years, and it will be nice if the same library package can be made to support both 2.x and 3.x. It would also be nice to define a way to specify that a tree of Python 2.7 scripts are to be compiled into Python 3.x bytecode, by specifying that the compilation process has first to run 2to3 (http://docs.python.org/py3k/library/2to3.html#to3-reference) on the Python scripts and actually compile the 2to3's output. --- Omer On Mon, 2010-04-19 at 17:53 -0400, Barry Warsaw wrote: On Friday, Guido approved and I landed the implementation of PEP 3147 on the py3k trunk (what will be Python 3.2). This allows multiple versions of Python to coexist on the same system without the need for symlinks to handle pyc file incompatibility. http://www.python.org/dev/peps/pep-3147/ This will be officially supported in Python starting with 3.2. It will not however be available in upstream Python 2.7. The PEP does recognize however that distros may want to back port the feature to get its advantages now. Although I have not yet tried to do so, I think the essential elements of the PEP should be fairly easy to back port to Python 2.6, 2.7 and 3.1. The question is, should we do this? -- $ python type(type(type)) type 'type' My own blog is at http://www.zak.co.il/tddpirate/ My opinions, as expressed in this E-mail message, are mine alone. They do not represent the official policy of any organization with which I may be affiliated in any way. WARNING TO SPAMMERS: at http://www.zak.co.il/spamwarning.html -- 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/1271735426.4405.10.ca...@c2.home.zak.co.il
Re: Final updates for this Python Policy revision
On Sat, 2009-12-12 at 14:27 +0100, Bastian Venthur wrote: Ben Finney schrieb: anatoly techtonik techto...@gmail.com writes: The policy is under GPL license which is kind of ridiculous to prevent citing Debian Policy in private talks. Why is it ridiculous? Is it any more ridiculous to put a policy document under GPL than any other document? Quoting the second paragraph from the copyright notice: This manual is free software; you can redistribute it... so this *manual* is free *software*. Really?! For me this wording shows clearly that this license does not fit to documentation since it was obviously made for software. The policy prescribes procedures to be followed by people who package Python packages for Debian, isn't it so? Couldn't we then consider it to be software, to be executed by the people who perform the packaging (to be considered as hardware, for this purpose alone)? Now that we put aside the philosophical issues, I'd like to clarify what can people do and what they cannot do with the policy document? As long as people can freely copy it, execute it (i.e. build packages according to its instructions), and modify it - I don't see why it should matter which license is chosen. It is not as if there are any commercial uses or whether we care about proprietaryclosed derivatives of the procedures. --- Omer -- Did you shave a yak today? My own blog is at http://www.zak.co.il/tddpirate/ My opinions, as expressed in this E-mail message, are mine alone. They do not represent the official policy of any organization with which I may be affiliated in any way. WARNING TO SPAMMERS: at http://www.zak.co.il/spamwarning.html -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
