On 24/10/05, glyph@divmod.com <glyph@divmod.com> wrote:

The main message here is that each Twisted subproject should be a coherent whole that performs an actual function. If .xish grew a tool for monitoring or transforming XML streams that would actually be useful to a reasonable-sized audience (i.e. not just for the author of the tool to test the library and not just so it can be split out ^_^), then it might be a good candidate for being split out into its own project again.

You know, by these standards, Trial is a good candidate for being split out into its own project. Now, sceptics might say, "ahh, but does not core depend on Trial?". To which I would say, "No it doesn't". cheers, jml

On Tue, 25 Oct 2005 14:19:40 +1100, Jonathan Lange <jml@mumak.net> wrote:

On 24/10/05, Jonathan Lange <jml@mumak.net> wrote:

...

On 24/10/05, glyph@divmod.com <glyph@divmod.com> wrote:

...

The main message here is that each Twisted subproject should be a coherent whole that performs an actual function. If .xish grew a tool for monitoring or transforming XML streams that would actually be useful to a reasonable-sized audience (i.e. not just for the author of the tool to test the library and not just so it can be split out ^_^), then it might be a good candidate for being split out into its own project again.

You know, by these standards, Trial is a good candidate for being split out into its own project.

Now, sceptics might say, "ahh, but does not core depend on Trial?". To which I would say, "No it doesn't".

Seriously, why don't we release Trial as a separate project?

Passing unit tests would be a good start towards that ;) Seriously: leaving twisted.protocols.loopback aside, I still think Core depends on Trial because Trial is how you can *tell* if Core is working: you run its tests. So Core depends on Trial, and Trial depends on core. If you must have both installed for either to work, is there really a benefit to packaging them separately? If you can suggest some other way to demonstrate that a Core install works, maybe you can convince me releasing trial separately has a purpose. Jp

On Tue, 25 Oct 2005 14:42:24 +1000, Andrew Bennetts <andrew-twisted@puzzling.org> wrote:

The fact that Trial is so clearly of use to other projects in exactly the same way that it's of use to core is another reason to have it seperate.

Trial and the rest of core are clearly developing at different rates, so there's possibly even some benefit from decoupling their releases.

So I think if Jonathan wants to release it seperately, I'm happy to let him.

Overall I'm a bit reluctant to spin out more new projects right now, but this actually sounds like a pretty compelling case to me. However, a point in JP's favor: there are source files distributed with core (twisted/test/*) that *import* code from Trial. Test cases seem to be, in every sense, a bit of a gnarly special case. Is there anything other than test cases where you think imports are *not* counted as a dependency?

Marcin Kasperski wrote:

...

However, a point in JP's favor: there are source files distributed with core (twisted/test/*) that *import* code from Trial. Test cases seem to be, in every sense, a bit of a gnarly special case. testcases are not necessary for production installation, just as technical docs are. In fact testcases, trial, docs etc are developer-environment tools, not production-environment tools.

I consider running unit tests an essential part of the build process. Thus, in my eyes twisted-core has a build-time dependency on trial, even if it doesn't have a runtime dependency.

On Wed, 26 Oct 2005 10:44:14 +1100, Jonathan Lange <jml@mumak.net> wrote:

Do you think a build-time dependency is enough to keep Trial within core?

It's not just build-time. Once you've installed Twisted in a particular environment, trial helps you determine if it's *installed* properly. If chunks have fallen off of your tarball at some point, trial will alert you to this by failing a bunch of tests. It's that dependency which keeps me leaning towards "yes". That said, I'm still undecided - trial is definitely making a lot of progress lately and the rationale of the split was to keep projects like this unconstrained by core's need for stability.

On Wed, 2005-10-26 at 18:58 +0300, Tommi Virtanen wrote:

Alternatively, wouldn't it be great if stdlib unittest, py.test and trial could _all_ run twisted core unit tests properly?-)

If py.test and stdlib unittest could run the tests without Trial *present*, that would mean we'd have to have a core API for running the reactor yourself in a test and shutting it down, so _NO_, that would not be great. This seems to a persistent meme though. I don't understand why you'd want to run the Twisted unittests with a non-Trial runner even *with* Trial installed, especially with Trial getting better all the time. One interpretation of this statement I could make that would in fact be great is that stdlib unittest and py.test could add support for returning Deferreds, but that would make them both alternative implementations of Trial, not of unittest (which is so vanishingly unlikely I can't imagine that's actually what you meant). Based on jml and spiv's earlier mails I presume that some effort is being put towards this. Insofar as this removes duplicate code from trial and uses the standard unittest implementations of things that unittest has an implementation of, great, but is there any more to it than that?

On Thu, 27 Oct 2005 12:52:37 +1100, Jonathan Lange <jml@mumak.net> wrote:

On 27/10/05, Glyph Lefkowitz <glyph@divmod.com> wrote:

(...) the reactor stuff is going in TestCase.

I believe I've lodged a disagreement with you before about this. If you really think it's best I'll trust your judgement more than mine, since you're certainly doing a bang-up job getting trial into useful shape, but I'll still try to convince you :). The reactor should be started by the command-line tool and stopped after all tests are done. Several reasons why: - Tests should be runnable by "live" processes. *twisted* context should need to be around, not unittest context, for the tests to run properly. This would help a lot in situations where something seems to work for the test framework but doesn't on a live server. - We try, but some event loops really *can't* be stopped and restarted safely or reliably multiple times within the same process. Previous discussions on this list I believe called out cfreactor as an example. I believe there are others. - Normal execution of Twisted programs has the Reactor start up once, lots of stuff run in it, and then it shuts down. I don't mind exercising the edge cases, but this _only_ excercises the edge cases; the reactor starts up and shuts down every time something new happens.

The advantages definitely include reduced duplication and less code to maintain. But another big advantage is that (when we're ready) Trial can use third-party extensions of unittest straight out of the box.

Are there any such third-party extensions which have value?

glyph@divmod.com wrote:

As an example of this, Twisted Matrix Labs' experience with distributing libraries has been, to put it politely, poor. Aside from .xish, whose function was mainly to complicate t.words releases and installations, our other two libraries are .pair and .flow, both of which are pretty much useless to everyone but their respective authors and currently unmaintained.

I fully expect twisted.pair to not release again without major changes. I feel the biggest reason it needed to be split from twisted.core was to give it a way to die. I will pick up twisted.pair (whether with that name or something else, whether as part of twisted or not) only when I get back to writing some DHCP code. Which is not likely to happen soon. Anyone suffering too badly from ISC, feel free to sponsor the work.

On 24/10/05, glyph@divmod.com <glyph@divmod.com> wrote:

The main message here is that each Twisted subproject should be a coherent whole that performs an actual function. If .xish grew a tool for monitoring or transforming XML streams that would actually be useful to a reasonable-sized audience (i.e. not just for the author of the tool to test the library and not just so it can be split out ^_^), then it might be a good candidate for being split out into its own project again.

You know, by these standards, Trial is a good candidate for being split out into its own project. Now, sceptics might say, "ahh, but does not core depend on Trial?". To which I would say, "No it doesn't". cheers, jml

On Tue, 25 Oct 2005 14:19:40 +1100, Jonathan Lange <jml@mumak.net> wrote:

On 24/10/05, Jonathan Lange <jml@mumak.net> wrote:

...

On 24/10/05, glyph@divmod.com <glyph@divmod.com> wrote:

...

The main message here is that each Twisted subproject should be a coherent whole that performs an actual function. If .xish grew a tool for monitoring or transforming XML streams that would actually be useful to a reasonable-sized audience (i.e. not just for the author of the tool to test the library and not just so it can be split out ^_^), then it might be a good candidate for being split out into its own project again.

You know, by these standards, Trial is a good candidate for being split out into its own project.

Now, sceptics might say, "ahh, but does not core depend on Trial?". To which I would say, "No it doesn't".

Seriously, why don't we release Trial as a separate project?

Passing unit tests would be a good start towards that ;) Seriously: leaving twisted.protocols.loopback aside, I still think Core depends on Trial because Trial is how you can *tell* if Core is working: you run its tests. So Core depends on Trial, and Trial depends on core. If you must have both installed for either to work, is there really a benefit to packaging them separately? If you can suggest some other way to demonstrate that a Core install works, maybe you can convince me releasing trial separately has a purpose. Jp

On Tue, 25 Oct 2005 14:42:24 +1000, Andrew Bennetts <andrew-twisted@puzzling.org> wrote:

The fact that Trial is so clearly of use to other projects in exactly the same way that it's of use to core is another reason to have it seperate.

Trial and the rest of core are clearly developing at different rates, so there's possibly even some benefit from decoupling their releases.

So I think if Jonathan wants to release it seperately, I'm happy to let him.

Overall I'm a bit reluctant to spin out more new projects right now, but this actually sounds like a pretty compelling case to me. However, a point in JP's favor: there are source files distributed with core (twisted/test/*) that *import* code from Trial. Test cases seem to be, in every sense, a bit of a gnarly special case. Is there anything other than test cases where you think imports are *not* counted as a dependency?

Marcin Kasperski wrote:

...

However, a point in JP's favor: there are source files distributed with core (twisted/test/*) that *import* code from Trial. Test cases seem to be, in every sense, a bit of a gnarly special case. testcases are not necessary for production installation, just as technical docs are. In fact testcases, trial, docs etc are developer-environment tools, not production-environment tools.

I consider running unit tests an essential part of the build process. Thus, in my eyes twisted-core has a build-time dependency on trial, even if it doesn't have a runtime dependency.

On Wed, 26 Oct 2005 10:44:14 +1100, Jonathan Lange <jml@mumak.net> wrote:

Do you think a build-time dependency is enough to keep Trial within core?

It's not just build-time. Once you've installed Twisted in a particular environment, trial helps you determine if it's *installed* properly. If chunks have fallen off of your tarball at some point, trial will alert you to this by failing a bunch of tests. It's that dependency which keeps me leaning towards "yes". That said, I'm still undecided - trial is definitely making a lot of progress lately and the rationale of the split was to keep projects like this unconstrained by core's need for stability.

On Wed, 2005-10-26 at 18:58 +0300, Tommi Virtanen wrote:

Alternatively, wouldn't it be great if stdlib unittest, py.test and trial could _all_ run twisted core unit tests properly?-)

If py.test and stdlib unittest could run the tests without Trial *present*, that would mean we'd have to have a core API for running the reactor yourself in a test and shutting it down, so _NO_, that would not be great. This seems to a persistent meme though. I don't understand why you'd want to run the Twisted unittests with a non-Trial runner even *with* Trial installed, especially with Trial getting better all the time. One interpretation of this statement I could make that would in fact be great is that stdlib unittest and py.test could add support for returning Deferreds, but that would make them both alternative implementations of Trial, not of unittest (which is so vanishingly unlikely I can't imagine that's actually what you meant). Based on jml and spiv's earlier mails I presume that some effort is being put towards this. Insofar as this removes duplicate code from trial and uses the standard unittest implementations of things that unittest has an implementation of, great, but is there any more to it than that?

On Thu, 27 Oct 2005 12:52:37 +1100, Jonathan Lange <jml@mumak.net> wrote:

On 27/10/05, Glyph Lefkowitz <glyph@divmod.com> wrote:

(...) the reactor stuff is going in TestCase.

I believe I've lodged a disagreement with you before about this. If you really think it's best I'll trust your judgement more than mine, since you're certainly doing a bang-up job getting trial into useful shape, but I'll still try to convince you :). The reactor should be started by the command-line tool and stopped after all tests are done. Several reasons why: - Tests should be runnable by "live" processes. *twisted* context should need to be around, not unittest context, for the tests to run properly. This would help a lot in situations where something seems to work for the test framework but doesn't on a live server. - We try, but some event loops really *can't* be stopped and restarted safely or reliably multiple times within the same process. Previous discussions on this list I believe called out cfreactor as an example. I believe there are others. - Normal execution of Twisted programs has the Reactor start up once, lots of stuff run in it, and then it shuts down. I don't mind exercising the edge cases, but this _only_ excercises the edge cases; the reactor starts up and shuts down every time something new happens.

The advantages definitely include reduced duplication and less code to maintain. But another big advantage is that (when we're ready) Trial can use third-party extensions of unittest straight out of the box.

Are there any such third-party extensions which have value?

glyph@divmod.com wrote:

As an example of this, Twisted Matrix Labs' experience with distributing libraries has been, to put it politely, poor. Aside from .xish, whose function was mainly to complicate t.words releases and installations, our other two libraries are .pair and .flow, both of which are pretty much useless to everyone but their respective authors and currently unmaintained.

I fully expect twisted.pair to not release again without major changes. I feel the biggest reason it needed to be split from twisted.core was to give it a way to die. I will pick up twisted.pair (whether with that name or something else, whether as part of twisted or not) only when I get back to writing some DHCP code. Which is not likely to happen soon. Anyone suffering too badly from ISC, feel free to sponsor the work.