On Wed, Mar 6, 2013 at 4:45 PM, Lennart Regebro wrote:
> Perhaps we can solve this outside distutils-sig so that distutils-sig
> can concentrate on the harder problems?
It's a distutils-sig problem because you need a way to publish any new
testing related metadata, and because we're planning to e
On Tue, Mar 5, 2013 at 9:25 AM, Nick Coghlan wrote:
> On Tue, Mar 5, 2013 at 5:02 PM, Lennart Regebro 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 su
On Tue, Mar 5, 2013 at 8:13 AM, Robert Collins
wrote:
> On 5 March 2013 20:02, Lennart Regebro 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 i
On Tue, Mar 5, 2013 at 8:11 AM, Donald Stufft 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 thi
On 6 Mar 2013 05:51, "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
> a
-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` wo
On Tue, Mar 5, 2013 at 2:49 PM, 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 ther
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 en
On 5 Mar 2013, at 09:02, Glyph wrote:
> On Mar 4, 2013, at 11:13 PM, Robert Collins 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
On 5 Mar 2013, at 07:19, Antoine Pitrou wrote:
> On Mon, 4 Mar 2013 15:47:37 -0800
> Eli Bendersky wrote:
>> On Mon, Mar 4, 2013 at 1:28 PM, Antoine Pitrou wrote:
>>
>>> On Mon, 4 Mar 2013 13:26:57 -0800
>>> Eli Bendersky wrote:
[Splitting into a separate thread]
Do we really
On Tue, Mar 5, 2013 at 10:02 AM, Glyph wrote:
> On Mar 4, 2013, at 11:13 PM, Robert Collins
> 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 l
On Mar 4, 2013, at 11:13 PM, Robert Collins 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,
On Tue, Mar 5, 2013 at 5:02 PM, Lennart Regebro 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 t
On Mon, 4 Mar 2013 15:47:37 -0800
Eli Bendersky wrote:
> On Mon, Mar 4, 2013 at 1:28 PM, Antoine Pitrou wrote:
>
> > On Mon, 4 Mar 2013 13:26:57 -0800
> > Eli Bendersky wrote:
> > > [Splitting into a separate thread]
> > >
> > > Do we really need to overthink something that requires a trivial a
On 5 March 2013 20:02, Lennart Regebro wrote:
> On Tue, Mar 5, 2013 at 1:41 AM, Robert Collins
> wrote:
>> So that is interesting, but its not sufficient to meet the automation
>> need Barry is calling out, unless all test suites can be run by
>> 'python -m unittest discover' with no additional p
On Tuesday, March 5, 2013 at 2:02 AM, Lennart Regebro wrote:
> On Tue, Mar 5, 2013 at 1:41 AM, Robert Collins
> mailto:robe...@robertcollins.net)> wrote:
> > So that is interesting, but its not sufficient to meet the automation
> > need Barry is calling out, unless all test suites can be run by
> >
On Tue, Mar 5, 2013 at 1:41 AM, Robert Collins
wrote:
> So that is interesting, but its not sufficient to meet the automation
> need Barry is calling out, unless all test suites can be run by
> 'python -m unittest discover' with no additional parameters [and a
> pretty large subset cannot].
But c
On Mar 05, 2013, at 01:09 PM, Robert Collins wrote:
>It isn't about length. It is about knowing that *that* is what to type
>(and btw that exact command cannot run twisted's tests, among many
>other projects tests).
>Perhaps we are talking about different things. A top level script to
>run tests
On 5 March 2013 13:35, Eli Bendersky wrote:
> Perhaps :-)
> I'm specifically referring to a new top-level script that will run all
> unittests in discovery mode from the current directory, as a shortcut to
> "python -m unittest discover". ISTM this is at leas in part what was
> discussed, and my
On Mon, Mar 4, 2013 at 4:09 PM, Robert Collins wrote:
> On 5 March 2013 12:49, Eli Bendersky wrote:
> >
> > On Mon, Mar 4, 2013 at 2:14 PM, Barry Warsaw wrote:
> >>
> >> On Mar 05, 2013, at 11:01 AM, Robert Collins wrote:
> >>
> >> >The big thing is automated tools, not developers.
> >>
> >> Exa
On 5 March 2013 12:49, Eli Bendersky wrote:
>
> On Mon, Mar 4, 2013 at 2:14 PM, Barry Warsaw wrote:
>>
>> On Mar 05, 2013, at 11:01 AM, Robert Collins wrote:
>>
>> >The big thing is automated tools, not developers.
>>
>> Exactly.
>
> I don't understand. Is "python -m unittest discover" too much t
On Mon, Mar 4, 2013 at 2:14 PM, Barry Warsaw wrote:
> On Mar 05, 2013, at 11:01 AM, Robert Collins wrote:
>
> >The big thing is automated tools, not developers.
>
> Exactly.
>
I don't understand. Is "python -m unittest discover" too much typing for
automatic tools? If anything, it's much more po
On Mon, Mar 4, 2013 at 1:28 PM, Antoine Pitrou wrote:
> On Mon, 4 Mar 2013 13:26:57 -0800
> Eli Bendersky 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
On Mar 05, 2013, at 11:01 AM, Robert Collins wrote:
>The big thing is automated tools, not developers.
Exactly.
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python
On 5 March 2013 10:26, Eli Bendersky 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?
The big thing is automated tools, not developers.
When distributors want to redistribute packages the
On Mon, 4 Mar 2013 13:26:57 -0800
Eli Bendersky 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 wro
[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 runpyte
27 matches
Mail list logo
