Re: [Python-Dev] built-in Python test runner (was: Python Language Summit at PyCon: Agenda)
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
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)
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)
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)
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)
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
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
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
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
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
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)
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)
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
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
-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
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
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)
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)
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)
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)
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