Is it worth back porting PEP 3147 to Python < 3.2?

[Barry Warsaw]

On Apr 26, 2010, at 06:35 PM, Nicolas Chauvat wrote:

>Nice to see someone of the core python team taking part in
>distribution development.

Well, it's official now - I've joined the Ubuntu platform team at Canonical,
so I'm very keen on helping to solve problems with Python on Debian and Ubuntu.

>On Thu, Apr 22, 2010 at 01:52:11PM -0400, Barry Warsaw wrote:
>> How much of the transition testing is automated?  It would be very interesting
>> for example, to have a test framework that could run any combination of Python
>> packages against various versions of Python, and get a report on the success
>> or failure of it.  This may not be a project for the distros of course - I
>> think upstream Python would be very interested in something like this.  For
>> example, a tool that grabbed packages from the Cheeseshop and tested them
>> against different versions would be cool.  If snakebite.org ever gets off the
>> ground, that might be the best place to put something like this together
>> (though we'd care less about OSes that aren't Debian and Ubuntu).
>
>Unfortunately, Logilab does not have a much man-power to offer to set
>this up at the moment, but would something like
>http://apycot.hg-scm.org/ fit your description of a test framework ?

That's for continuous integration of Mercurial, right?

>We also have it running at logilab.org and cubicweb.org of course:
>http://www.logilab.org/view?rql=testconfig&vid=summary
>http://www.cubicweb.org/view?rql=testconfig&vid=summary
>
>As you can see with these second and third links, tests include
>lintian and piuparts checks. 
>
>Is it something like this that you had in mind?

Yes.  What are you using to drive this?  I'm not really up on CI tools, but
Hudson has been getting a lot of buzz.

http://hudson-ci.org/

What I like about your display is that a failure in one area does not
necessary mean a failure elsewhere.  That way you can better see the overall
health of the package.

What I have in mind is defining a set of best practices, embodied as much as
possible in tools and libraries, that provide carrots to Python developers, so
that if they adhere to these best practices, the can get lots of benefits such
as nearly automatic and effortless packaging in Debian and Ubuntu.  It's
things like 'python setup.py test' just working, and it has an impact on PyPI,
documentation, release management, etc.  These best practices can be
opinionated and simple.  If they cover only 80% of Python packages, that's
fine.  Developers would never be forced to adhere to them, but it would be to
their advantage to do so.

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
Url : https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20100426/a68daa97/attachment.pgp