Re: [Python-Dev] built-in Python test runner (was: Python Language Summit at PyCon: Agenda)

2013-03-05 Thread Nick Coghlan
On Tue, Mar 5, 2013 at 5:02 PM, Lennart Regebro rege...@gmail.com wrote:
 I don't care much what that mechanism is, but I think the easiest way
 to get there is to tell people to extend distutils with a test command
 (or use Distribute) and perhaps add such a command in 3.4 that will do
 the unittest discover thingy. I remember looking into zope.testrunner
 hooking into that mechanism as well, but I don't remember what the
 outcome was.

There is no easy way forward at this point in time. There just isn't.
If people want to dispute that claim, please feel free to solve all
the other problems distutils-sig is trying to tackle, so we can pay
attention to this one.

We'll get to this eventually - there are just several other more
important things ahead of it in the queue for packaging and
distribution infrastructure enhancements (and python-dev is not the
group that will solve them).

Regards,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Introducing Electronic Contributor Agreements

2013-03-05 Thread Stephen J. Turnbull
Terry Reedy writes:

   or a proposal for a change that is given within a bug tracker message?
  
  I view a proposal for a change as just an idea. Such usually get 
  re-written by whoever creates an actual patch.

Precisely how U.S. law would view it, implying no copyright issue.

If this really need further discussion, it should move to
python-legal.

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] built-in Python test runner (was: Python Language Summit at PyCon: Agenda)

2013-03-05 Thread Glyph
On Mar 4, 2013, at 11:13 PM, Robert Collins robe...@robertcollins.net wrote:

 In principle maybe. Need to talk with the trial developers, nose
 developers, py.test developers etc - to get consensus on a number of
 internal API friction points.

Some of trial's lessons might be also useful for the stdlib going forward, 
given the hope of doing some event-loop stuff in the core.

But, I feel like this might be too much to cover at the language summit; there 
could be a test frameworks summit of its own, of about equivalent time and 
scope, and we'd still have a lot to discuss.

Is there a unit testing SIG someone from Twisted ought to be a member of, to 
represent Trial, and to get consensus on these points going forward?

-glyph

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] built-in Python test runner (was: Python Language Summit at PyCon: Agenda)

2013-03-05 Thread Holger Krekel
On Tue, Mar 5, 2013 at 10:02 AM, Glyph gl...@twistedmatrix.com wrote:

 On Mar 4, 2013, at 11:13 PM, Robert Collins robe...@robertcollins.net
 wrote:

 In principle maybe. Need to talk with the trial developers, nose
 developers, py.test developers etc - to get consensus on a number of
 internal API friction points.


 Some of trial's lessons might be also useful for the stdlib going forward,
 given the hope of doing some event-loop stuff in the core.

 But, I feel like this might be too much to cover at the language summit;
 there could be a test frameworks summit of its own, of about equivalent
 time and scope, and we'd still have a lot to discuss.

 Is there a unit testing SIG someone from Twisted ought to be a member of,
 to represent Trial, and to get consensus on these points going forward?


The testing-in-python list is pretty much where most test tool authors hang
out, see  http://lists.idyll.org/listinfo/testing-in-python

Also, maybe related, i am heading the tox effort which many people use to
have a frontend for their testing process, see http://tox.testrun.org -- it
has a somewhat different focus in that it sets up virtualenv and install
test specific dependencies.  However, positional arguments (often used to
select tests) can be configured to be passed on to the test runner of
choice. I was considering extending tox to directly support nose, pytest,
unittest and trial drivers and offer a unified (minimal) command line
API.  Am open to collaboration on that.

cheers,
holger



 -glyph


 ___
 Python-Dev mailing list
 Python-Dev@python.org
 http://mail.python.org/mailman/listinfo/python-dev
 Unsubscribe:
 http://mail.python.org/mailman/options/python-dev/holger.krekel%40gmail.com


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] built-in Python test runner (was: Python Language Summit at PyCon: Agenda)

2013-03-05 Thread Michael Foord

On 5 Mar 2013, at 07:19, Antoine Pitrou solip...@pitrou.net wrote:

 On Mon, 4 Mar 2013 15:47:37 -0800
 Eli Bendersky eli...@gmail.com wrote:
 On Mon, Mar 4, 2013 at 1:28 PM, Antoine Pitrou solip...@pitrou.net wrote:
 
 On Mon, 4 Mar 2013 13:26:57 -0800
 Eli Bendersky eli...@gmail.com wrote:
 [Splitting into a separate thread]
 
 Do we really need to overthink something that requires a trivial alias to
 set up for one's own convenience?
 
 Picking a Python version (as Barry mentions) is just one of the problems.
 What's wrong with:
 
 alias rupytests='python3 -m unittest discover
 alias runpytests2='python2 -m unittest discover
 
 ?
 
 Don't get me wrong, I love the discover option and agree that it should
 be the recommended way to go - but isn't this largely a documentation
 issue?
 
 I would personally call it a typing issue :-) python -m unittest
 discover is just too long.
 
 
 Command-line options for advanced capabilities can get long, yes.
 
 The whole point is that discovery is not advanced capability, it's
 pretty basic by today's standards. So it should actually be the default
 behaviour (like it is with nose).
 


For Python 3.3 onwards python -m unittest does run test discovery by default. 
However if you want to provide parameters you still need the discover 
subcommand to disambiguate from the other command line options. So I agree - a 
shorthand command would be an improvement.

Michael



 Regards
 
 Antoine.
 
 
 ___
 Python-Dev mailing list
 Python-Dev@python.org
 http://mail.python.org/mailman/listinfo/python-dev
 Unsubscribe: 
 http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk


--
http://www.voidspace.org.uk/


May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing 
http://www.sqlite.org/different.html





___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] built-in Python test runner (was: Python Language Summit at PyCon: Agenda)

2013-03-05 Thread Michael Foord

On 5 Mar 2013, at 09:02, Glyph gl...@twistedmatrix.com wrote:

 On Mar 4, 2013, at 11:13 PM, Robert Collins robe...@robertcollins.net wrote:
 
 In principle maybe. Need to talk with the trial developers, nose
 developers, py.test developers etc - to get consensus on a number of
 internal API friction points.
 
 Some of trial's lessons might be also useful for the stdlib going forward, 
 given the hope of doing some event-loop stuff in the core.
 
 But, I feel like this might be too much to cover at the language summit; 
 there could be a test frameworks summit of its own, of about equivalent time 
 and scope, and we'd still have a lot to discuss.
 
 Is there a unit testing SIG someone from Twisted ought to be a member of, to 
 represent Trial, and to get consensus on these points going forward?


The testing-on-python mailing list is probably the best place (and if doesn't 
have that status already I'd be keen to elevate it to official sig for Python 
testing issues status).

http://lists.idyll.org/listinfo/testing-in-python

Like the massively distributed testing use case, I'd be very happy for the 
standard library testing capabilities to better support this use case - but I 
wouldn't like to design their apis around that as the sole use case. :-)

Michael

 
 -glyph
 
 ___
 Python-Dev mailing list
 Python-Dev@python.org
 http://mail.python.org/mailman/listinfo/python-dev
 Unsubscribe: 
 http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk


--
http://www.voidspace.org.uk/


May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing 
http://www.sqlite.org/different.html





___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Python Language Summit at PyCon: Agenda

2013-03-05 Thread Michael Foord

On 5 Mar 2013, at 05:39, Jeff Hardy jdha...@gmail.com wrote:

 On Mon, Mar 4, 2013 at 4:39 PM, Michael Foord fuzzy...@voidspace.org.uk 
 wrote:
 
 On 1 Mar 2013, at 18:38, Antoine Pitrou solip...@pitrou.net wrote:
 
 On Fri, 1 Mar 2013 09:32:23 -0500
 Barry Warsaw ba...@python.org wrote:
 
 On the other hand in some ways Jython is sort of like Python on a
 weird virtual OS that lets the real OS bleed through some. This may
 still need to be checked in that way (there's are still checks of if
 os.name == 'nt' right?)
 
 Yeah, but that all old code ;)
 
 Hmm, what do you mean? `os.name == 'nt'` is still the proper way to
 test that we're running on a Windows system (more accurately, over the
 Windows API).
 
 
 It has been used incorrectly in a few places in the Python standard library 
 - Windows support code that would work correctly on IronPython is skipped 
 because os.name is *not* 'nt' on IronPython.  That was the case in the past 
 anyway. It's quite some time since I've used IronPython now.
 
 I think you misremembered - there's lots of code that uses
 `sys.platform == 'win32'` to detect Windows, but sys.platform is 'cli'
 for IronPython. I'm pretty sure `os.name has always been 'nt' (when
 running on Windows), and if not, it definitely is now.
 
 Jython sets os.name to 'java' (IIRC), so there isn't a uniform way to
 detect Windows across all implementations.
 


Ah, I'm sure you're correct. 

Thanks.

 - Jeff


--
http://www.voidspace.org.uk/


May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing 
http://www.sqlite.org/different.html





___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Introducing Electronic Contributor Agreements

2013-03-05 Thread Ezio Melotti
Hi,

On Mon, Mar 4, 2013 at 10:46 PM, Terry Reedy tjre...@udel.edu wrote:
 On 3/4/2013 11:36 AM, Brett Cannon wrote:
 On Mon, Mar 4, 2013 at 11:30 AM, Brian Curtin br...@python.org
 mailto:br...@python.org wrote:

 With this in place I would like to propose that all patches submitted to
 bugs.python.org http://bugs.python.org must come from someone who has

 signed the CLA before we consider committing it (if you want to be truly
 paranoid we could say that we won't even look at the code w/o a CLA).


 Either policy could be facilitated by tracker changes. In order to see the
 file upload box, one must login and the tracker knows who has a CLA on file
 (as indicated by a * suffix on the name). If a file is uploaded by someone
 without, a box could popup with the link to the e-form and a message that a
 CLA is required.


http://psf.upfronthosting.co.za/roundup/meta/issue461

Best Regards,
Ezio Melotti

 --
 Terry Jan Reedy

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Introducing Electronic Contributor Agreements

2013-03-05 Thread Baptiste Carvello
Le 05/03/2013 04:13, Stephen J. Turnbull a écrit :
 Mark Lawrence writes:
 
   People already use the bug tracker as an excuse not to contribute, 
   wouldn't this requirement make the situation worse?
 
 A failure to sign the CLA is already a decision not to contribute to
 the distribution

my 2 cents as an occasional contributor of minor patches: I understand
that the scarce resource is reviewer time, so I would definitely accept
to sign the CLA with my next contribution before a reviewer invests his
time in it.

However, please don't make the popup too pushy. I abhor websites which
push people into entering legally binding agreements with one click
without the opportunity to study them carefully (personnally, this would
not be a problem as I already know what the CLA is about, but other
contributors might not).

Also, please keep the possibility to use the old paper-based signing
procedure. I for one don't consider so-called electronic signatures
based on email address verification (as opposed to real crypto) to be as
good as a handwritten signature, and I don't want to legitimize them by
using them.

Cheers,
Baptiste

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Python Language Summit at PyCon: Agenda

2013-03-05 Thread fwierzbi...@gmail.com
On Mon, Mar 4, 2013 at 9:39 PM, Jeff Hardy jdha...@gmail.com wrote:
 I think you misremembered - there's lots of code that uses
 `sys.platform == 'win32'` to detect Windows, but sys.platform is 'cli'
 for IronPython. I'm pretty sure `os.name has always been 'nt' (when
 running on Windows), and if not, it definitely is now.

 Jython sets os.name to 'java' (IIRC), so there isn't a uniform way to
 detect Windows across all implementations.
I've been thinking that this is a bit of a historical mistake on our
part. I'm strongly considering setting os.name properly in Jython3.

-Frank
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Python Language Summit at PyCon: Agenda

2013-03-05 Thread fwierzbi...@gmail.com
On Tue, Mar 5, 2013 at 8:55 AM, fwierzbi...@gmail.com
fwierzbi...@gmail.com wrote:
 I've been thinking that this is a bit of a historical mistake on our
 part. I'm strongly considering setting os.name properly in Jython3.
In fairness to Jython implementers past - it wasn't a mistake but a
deliberate design choice at the time since in the old days we where
going for the now defunct 100% Java thing (does anyone remember
that?) so this is more of the design has evolved such that Jython's
os.name now feels incorrect.

I'll stop having conversations with myself in public now, sorry :)

-Frank
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] built-in Python test runner (was: Python Language Summit at PyCon: Agenda)

2013-03-05 Thread Barry Warsaw
On Mar 05, 2013, at 02:11 AM, Donald Stufft wrote:

Doesn't setuptools/distribute already have a setup.py test command? That
seems like the easiest way forward? 

Yes, and in theory it can make `python setup.py test` work well.  But there
are lots of little details (such as API differences for ensuring that doctests
run, additional tests discovery, etc.) that make this often not work so well
in practice.  Some of that is social and some of it is technical.  I still
claim that including test suite information in a package's metadata would be a
win, but maybe that's just too much to hope for right now.

-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] built-in Python test runner (was: Python Language Summit at PyCon: Agenda)

2013-03-05 Thread Daniel Holth
On Tue, Mar 5, 2013 at 2:49 PM, Barry Warsaw ba...@python.org wrote:
 On Mar 05, 2013, at 02:11 AM, Donald Stufft wrote:

Doesn't setuptools/distribute already have a setup.py test command? That
seems like the easiest way forward?

 Yes, and in theory it can make `python setup.py test` work well.  But there
 are lots of little details (such as API differences for ensuring that doctests
 run, additional tests discovery, etc.) that make this often not work so well
 in practice.  Some of that is social and some of it is technical.  I still
 claim that including test suite information in a package's metadata would be a
 win, but maybe that's just too much to hope for right now.

It would be a win, but parsing the metadata is just not what happens
right now, let alone writing anything about which and where the
modules are defined in the sdist. We can barely install packages by
using the dependency metadata from PKG-INFO; pip always re-generates
it from setup.py egg_info.

Your testing metadata prototype would only have to write two lines to
the metadata instead of one a-la: Extension: flufl; flufl/test_suite:
nose.collector; document the extension; write some tool to actually
parse the metadata and invoke the tests; it may become a core feature
in the next version, or having a monolithic specification may become
less important.

Thanks,

Daniel Holth
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Introducing Electronic Contributor Agreements

2013-03-05 Thread Brett Cannon
On Tue, Mar 5, 2013 at 11:48 AM, Baptiste Carvello 
de...@baptiste-carvello.net wrote:

 Le 05/03/2013 04:13, Stephen J. Turnbull a écrit :
  Mark Lawrence writes:
 
People already use the bug tracker as an excuse not to contribute,
wouldn't this requirement make the situation worse?
 
  A failure to sign the CLA is already a decision not to contribute to
  the distribution

 my 2 cents as an occasional contributor of minor patches: I understand
 that the scarce resource is reviewer time, so I would definitely accept
 to sign the CLA with my next contribution before a reviewer invests his
 time in it.

 However, please don't make the popup too pushy. I abhor websites which
 push people into entering legally binding agreements with one click
 without the opportunity to study them carefully (personnally, this would
 not be a problem as I already know what the CLA is about, but other
 contributors might not).

 Also, please keep the possibility to use the old paper-based signing
 procedure. I for one don't consider so-called electronic signatures
 based on email address verification (as opposed to real crypto) to be as
 good as a handwritten signature, and I don't want to legitimize them by
 using them.


At the bottom of the CLA page there are instructions on how to still use
the paper form.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] built-in Python test runner

2013-03-05 Thread Donald Stufft
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Barry Warsaw wrote:
 On Mar 05, 2013, at 02:11 AM, Donald Stufft wrote:
 
 Doesn't setuptools/distribute already have a setup.py test command?
 That seems like the easiest way forward?
 
 Yes, and in theory it can make `python setup.py test` work well.  But
 there are lots of little details (such as API differences for
 ensuring that doctests run, additional tests discovery, etc.) that
 make this often not work so well in practice.  Some of that is social
 and some of it is technical.  I still claim that including test suite
 information in a package's metadata would be a win, but maybe that's
 just too much to hope for right now.

For the right now solution you can easily override the test command
in setup.py. Long term this would be something that could be added to
the METADATA but I think it is (and rightly should be) lower priority
to actually getting it working for it's core purpose.

 
 -Barry ___ Python-Dev
 mailing list Python-Dev@python.org 
 http://mail.python.org/mailman/listinfo/python-dev Unsubscribe:
 http://mail.python.org/mailman/options/python-dev/donald%40stufft.io
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)

iQIcBAEBAgAGBQJRNlaJAAoJEG48vOkzctz6SvsP/2+MYkn1NgcHdmaQg09A3MDH
a++7+hGGsXgQwwJ3q3u6T6Hzd1pokJI7hqGHAXBnkODrZZ8f9Z0+OP9I8HPUmo0D
mJDsDxn2VZImBkNZJlBGNFKIz4EjS5llFapzdl58ZkIVZ7Rz3PTaPVSiXOc+ppp7
xYkWXGnx+2DTFaHywi9qGsHrbAXqgcwIhXO29NYl98xA9X98/XSRiXmHVfNURA3U
1GV1G9H1Qfvu8YjfYfBCCUn6db6eLGVPO7VcxRh6Cyzfk5SFSuziCVI8v3t3msjw
KSba+8Pe3RQ7RS17VEJqCMQjkhhGnAndgIL3Jho41qb3g+Rdk2OP+weWbYV92Q8F
HL6QtPgm5/QS5tKyl6nK97+9q+NdhGOEzKOL0pBiF4HKdT0mKyBxqttVIgUDAVMQ
XcjhBu1wnpQnhkeZ8F3yGNubmE2tRdVVfhTfVDaA3ICl7uVBlbtUUMTJRK7DQ4vW
gzDk5aKJB8OHimC1ijeTQm3M2lXkS5z0e5IuaION2WrG5A2BEvH12d/I7ekc1Ixa
lVhScABFwY0UcrMt4td65er/w4Z0S+BL87SZMH1mffoS6XmL3fxUuOtAB+MUWDk7
Rd4xXnUFvr3SMmMRjSogpO/HO5IBpuzUwu0wqSz8qPcex+l+lHyOEHBDvacEcv9b
zvGYjfQuk+2hWlAqw5o4
=6ELp
-END PGP SIGNATURE-
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


[Python-Dev] tp_dictoffset and tp_weaklistoffset slots for Stable API

2013-03-05 Thread Andrew Svetlov
Looking on PEP http://www.python.org/dev/peps/pep-0384/ and docs I
don't figure out how to specify this values.

Maybe I've missed something?

If not I like to solve that problem at us pycon sprints.
Hope, Martin von Loewis will visit the conference.

--
Thanks,
Andrew Svetlov
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Introducing Electronic Contributor Agreements

2013-03-05 Thread R. David Murray
On Tue, 05 Mar 2013 15:22:07 -0500, Brett Cannon br...@python.org wrote:
 On Tue, Mar 5, 2013 at 11:48 AM, Baptiste Carvello 
 de...@baptiste-carvello.net wrote:
 
  Le 05/03/2013 04:13, Stephen J. Turnbull a écrit :
   Mark Lawrence writes:
  
 People already use the bug tracker as an excuse not to contribute,
 wouldn't this requirement make the situation worse?
  
   A failure to sign the CLA is already a decision not to contribute to
   the distribution
 
  my 2 cents as an occasional contributor of minor patches: I understand
  that the scarce resource is reviewer time, so I would definitely accept
  to sign the CLA with my next contribution before a reviewer invests his
  time in it.
 
  However, please don't make the popup too pushy. I abhor websites which
  push people into entering legally binding agreements with one click
  without the opportunity to study them carefully (personnally, this would
  not be a problem as I already know what the CLA is about, but other
  contributors might not).
 
  Also, please keep the possibility to use the old paper-based signing
  procedure. I for one don't consider so-called electronic signatures
  based on email address verification (as opposed to real crypto) to be as
  good as a handwritten signature, and I don't want to legitimize them by
  using them.
 
 
 At the bottom of the CLA page there are instructions on how to still use
 the paper form.

Then there also needs to be a way to ACK the popup so that it never
shows up again.  Which we should have anyway.  Ideally that would be
tied to the account and not to, say, a browser cookie.

--David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] built-in Python test runner (was: Python Language Summit at PyCon: Agenda)

2013-03-05 Thread Nick Coghlan
On 6 Mar 2013 05:51, Barry Warsaw ba...@python.org wrote:

 On Mar 05, 2013, at 02:11 AM, Donald Stufft wrote:

 Doesn't setuptools/distribute already have a setup.py test command? That
 seems like the easiest way forward?

 Yes, and in theory it can make `python setup.py test` work well.  But
there
 are lots of little details (such as API differences for ensuring that
doctests
 run, additional tests discovery, etc.) that make this often not work so
well
 in practice.  Some of that is social and some of it is technical.  I still
 claim that including test suite information in a package's metadata would
be a
 win, but maybe that's just too much to hope for right now.

I think it's the right answer, too, but PEP 426 is already huge, so
metadata 2.1 is likely the earliest we will try to tackle the problem.

Cheers,
Nick.


 -Barry
 ___
 Python-Dev mailing list
 Python-Dev@python.org
 http://mail.python.org/mailman/listinfo/python-dev
 Unsubscribe:
http://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] built-in Python test runner (was: Python Language Summit at PyCon: Agenda)

2013-03-05 Thread Lennart Regebro
On Tue, Mar 5, 2013 at 8:11 AM, Donald Stufft donald.stu...@gmail.com wrote:
 I don't care much what that mechanism is, but I think the easiest way
 to get there is to tell people to extend distutils with a test command
 (or use Distribute) and perhaps add such a command in 3.4 that will do
 the unittest discover thingy. I remember looking into zope.testrunner
 hooking into that mechanism as well, but I don't remember what the
 outcome was.

 Doesn't setuptools/distribute already have a setup.py test command?

Yes, but distutils do not.

 That seems like the easiest way forward?

Yup. Although I can understand people if they want something that is
independent of packaging/distribution.

//Lennart
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] built-in Python test runner (was: Python Language Summit at PyCon: Agenda)

2013-03-05 Thread Lennart Regebro
On Tue, Mar 5, 2013 at 8:13 AM, Robert Collins
robe...@robertcollins.net wrote:
 On 5 March 2013 20:02, Lennart Regebro rege...@gmail.com wrote:
 What's needed here is not a tool that can run all unittests in
 existence, but an official way for automated tools to run tests, with
 the ability for any test and test framework to hook into that, so that
 you can run any test suite automatically from an automated tool. The,
 once that mechanism has been identified/implemented, we need to tell
 everybody to do this.

 I think the command line is the right place to do that - declare as
 metadata the command line to run a packages tests.

Yeah, that's good and simple solution.

//Lennart
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] built-in Python test runner (was: Python Language Summit at PyCon: Agenda)

2013-03-05 Thread Lennart Regebro
On Tue, Mar 5, 2013 at 9:25 AM, Nick Coghlan ncogh...@gmail.com wrote:
 On Tue, Mar 5, 2013 at 5:02 PM, Lennart Regebro rege...@gmail.com wrote:
 I don't care much what that mechanism is, but I think the easiest way
 to get there is to tell people to extend distutils with a test command
 (or use Distribute) and perhaps add such a command in 3.4 that will do
 the unittest discover thingy. I remember looking into zope.testrunner
 hooking into that mechanism as well, but I don't remember what the
 outcome was.

 There is no easy way forward at this point in time. There just isn't.
 If people want to dispute that claim, please feel free to solve all
 the other problems distutils-sig is trying to tackle, so we can pay
 attention to this one.

I have to admit that of all the packaging problems out there, this is
one of the easiest ones. ;-)
That said, it's not easy.

 We'll get to this eventually - there are just several other more
 important things ahead of it in the queue for packaging and
 distribution infrastructure enhancements (and python-dev is not the
 group that will solve them).

To be honest I'm not sure distutils-sig is the right place for this.
It's really only a packaging problem because Setuptools has a test
command. :-)
Perhaps we can solve this outside distutils-sig so that distutils-sig
can concentrate on the harder problems?

//Lennart
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com