Re: TB2::Mouse will be internal use only... with one hitch.
Sorry for the long delay. Lately I'm task-switching at a slow pace. Also, I'm quoting you out of order. * Michael G Schwern schw...@pobox.com [2011-11-30T17:16:47] RJBS wrote, The only case when the programmer needs to know about the Mouse underpinnings is when hacking on the dist itself, not not ever reasonable extensions? Yes, unless you consider writing a Formatter and altering the behavior of the whole Test process to be reasonable. I feel like it's weird if Test::Builder v2 is delivered with the notice, any additional formatter classes must be made internal to Test-Builder, as they must rely on a for-internal-use library. Writing additional formatters is not a reasonable extension. That's what it sounds like, if you're saying that: a) TB2::Mouse is for internal use only b) nothing outside the dist should be using it c) it is unreasonable to write a new Formatter I mean, if you are saying those things, okay! I'm just surprised. TB2 will use Mouse if Mouse is available. [1] Otherwise it will use TB2::Mouse, its bundled and namespace altered copy of Mouse::Tiny. As far as any extensions are concerned, TB2 uses Mouse since must depend on Mouse. This behavior worries me more than anything else. Everything depends on Test::Builder. I'm too lazy to do the legwork right now, but I think we can agree that the vast majority of CPAN distributions with tests use Test::Builder for their tests. The opportunistic loading of Mouse means that nearly *every dist* has the possibility to change its test-time behavior based on an undeclared optional library. [ extremely long, boring, elaborate example written then removed ] I'm concerned about the action at a distance. A change to Mouse can cause a change in Test::Builder, if it really uses Mouse and not just a CP of it. If a distribution at one point in someone's massive dependency tree starts requiring Mouse, and is installed early, it could change the behavior of the subsequently installed distributions, and the change will probably be completely baffling to the user. I am only a little bit comforted by But the Mouse team will be testing TB2 before any release! The biggest reason is that they won't be testing every extension to the Test::Builder framework that might be in play. If writing those extensions is unreasonable for anyone outside of the Test-Builder dist to do, then maybe folks get what they deserve, but if that's the case, nobody needs to write use Mouse::Role for a TB2 role, so the only reason to load Mouse is to get Mouse::XS, which doesn't seem, to me and at first glance, like the right trade-off. If speed is the issue, and people know that their tests are too slow because of the lack of Mouse XS, I wonder whether TB2_USE_MOUSE=1 isn't the answer. Then at least you're opting in to the risk. -- rjbs
Re: TB2::Mouse will be internal use only... with one hitch.
On Nov 30, 2011, at 7:31 PM, brian d foy wrote: I'm not saying that you should dump Mouse, but when I see a design decision reach this far into the world (when nobody should have ever noticed it), I generally think it's time to consider if it was really a good idea. However, I have no experience with TB2 development. As a person who will have to subclass TB2, I'm really not looking forward to any of this. I shouldn't have to deal or even know about the TB2 internals. Yes, but I would view this as a symptom of a failure of core Perl more than anything else. We really need a MOP and the attendant infrastructure and syntax for classes, methods, and roles in the language. The alternative is having to deal with issues like this. Best, David
Re: TB2::Mouse will be internal use only... with one hitch.
On Wed, Nov 30, 2011 at 11:07 PM, David E. Wheeler da...@justatheory.com wrote: Yes, but I would view this as a symptom of a failure of core Perl more than anything else. We really need a MOP and the attendant infrastructure and syntax for classes, methods, and roles in the language. The alternative is having to deal with issues like this. +1 Amen! -- David
Re: TB2::Mouse will be internal use only... with one hitch.
On Wed, Nov 30, 2011 at 12:39 AM, Michael G Schwern schw...@pobox.com wrote: There is a 3rd choice, which brings us full circle to where this discussion started. We write TB2::Object [1] to select load Mouse if its available, TB2::Mouse otherwise. That way TB2 classes are compatible with Mouse just in time. They also get a performance kick. The core gets the for internal use only marked TB2::Mouse as previously discussed. Without commenting on the rest of the plan, to which I want to give a little more thought, it occurs to me TB2 as released to CPAN could explicitly depend on Mouse, so that any TB2 installed (or upgraded) via CPAN client gets Mouse installed (or upgraded). Meanwhile, the TB2 in Perl core could rely only TB2::Mouse as a temporary shim until someone upgrades their TB2. That might be good or bad policy depending on how one wants to look at it as a precedent for core modules, but it does deal with this particular issue pragmatically. -- David
Re: TB2::Mouse will be internal use only... with one hitch.
On Nov 29, 2011, at 9:39 PM, Michael G Schwern wrote: 1. The core gets a shrouded copy of Mouse::Tiny, with different namespaces, as discussed at the beginning. 2. TB2 gets a performance kick once Mouse is installed. 3. Extension authors can use Mouse to subclass TB2 and consume TB2 roles as normal. 4. TB2 continues to be able to take full advantage of Mouse. Nobody needs to ever know there's a copy of Mouse::Tiny in there. Thoughts? How much slower will this make running the core tests, since neither Mouse nor Mouse::XS will every be available there (during development, at core installation time). Best, David
Re: TB2::Mouse will be internal use only... with one hitch.
On 2011.11.30 2:04 AM, David Golden wrote: On Wed, Nov 30, 2011 at 12:39 AM, Michael G Schwern schw...@pobox.com wrote: There is a 3rd choice, which brings us full circle to where this discussion started. We write TB2::Object [1] to select load Mouse if its available, TB2::Mouse otherwise. That way TB2 classes are compatible with Mouse just in time. They also get a performance kick. The core gets the for internal use only marked TB2::Mouse as previously discussed. Without commenting on the rest of the plan, to which I want to give a little more thought, it occurs to me TB2 as released to CPAN could explicitly depend on Mouse, so that any TB2 installed (or upgraded) via CPAN client gets Mouse installed (or upgraded). Unfortunately, that would be a circular dependency between Mouse and TB2 unless... * Mouse never depends on Test::More newer than the one which shipped with 5.8.1 (0.47). This is a bit much to ask of the Mouse folks. They're already using 0.88 and I don't want to make their life harder to make mine easier. * Mouse bundles Test::More. A distinct possibility. You'd put all the .pm files into t/lib and then Cuse lib t/lib in each test. Modules used to do this all the time, when we weren't sure about this whole new fangled Test::More thing and module authors complained bitterly about having to add a dependency just for testing. -- But there's no sense crying over every mistake. You just keep on trying till you run out of cake. -- Jonathan Coulton, Still Alive
Re: TB2::Mouse will be internal use only... with one hitch.
On Wed, Nov 30, 2011 at 6:13 AM, Michael G Schwern schw...@pobox.com wrote: Unfortunately, that would be a circular dependency between Mouse and TB2 unless... Not a complete dependency, though, as one can function without the other. As long as the CPAN clients are smart enough not to follow the prereq chain endlessly, it might work. E.g. * install Mouse -- requires TB2 -- TB2 requires Mouse and client ignores repeat. TB2 passes test by falling back on TB::Mouse. Mouse tests find TB2 and pass. * install TB2 -- requires Mouse -- Mouse requires TB2 and client ignores repeat. Mouse tests fail (ugly!). TB2 fails to find Mouse, falls back and passes. That second case only happens if TB2 has *never* been installed on a system (or if it's too old to meet Mouse's needs). And possibly TB2's Makefile could be smart and only add the Mouse prereq if it finds a version of itself (or, really, of Test::More) sufficient to meet Mouse's prereq needs. (Bundling might still be easier.) Another idea might be for TB2 to use the new runtime/recomends prereq type in v2 CPAN Meta files. One of my Paris QA hackathon goals is to teach at least CPAN.pm (and maybe the other CPAN clients) to do something useful with the new prereq types, and useful might include something smart when a recommendation fails. (E.g. letting it happen without complaining). The definition of useful is one of the things I want to debate over meals there in the non-coding hours. :-) -- David
Re: TB2::Mouse will be internal use only... with one hitch.
On 2011.11.30 4:31 AM, David Golden wrote: On Wed, Nov 30, 2011 at 6:13 AM, Michael G Schwern schw...@pobox.com wrote: Unfortunately, that would be a circular dependency between Mouse and TB2 unless... Not a complete dependency, though, as one can function without the other. As long as the CPAN clients are smart enough not to follow the prereq chain endlessly, it might work. *All* CPAN clients. This includes package builders, DarkPAN tools, and so on. Circular dependencies are bad juju. Putting one at the root of the dependency tree would be asking for disaster. It risks breaking the whole automated CPAN bootstrapping and upgrading process. And possibly TB2's Makefile could be smart and only add the Mouse prereq if it finds a version of itself (or, really, of Test::More) sufficient to meet Mouse's prereq needs. (Bundling might still be easier.) That might work. It puts information about Mouse into the Test-Simple distribution. Information which will change. It means the two distributions must be coupled even more tightly. If Mouse changes its Test::More dep, a new version of Test::More must be cut immediately if not before the Mouse change. Very time sensitive. Another idea might be for TB2 to use the new runtime/recomends prereq type in v2 CPAN Meta files. Same problem as a regular prereq as they are resolved before building and installation. -- 10. Not allowed to purchase anyone's soul on government time. -- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army http://skippyslist.com/list/
Re: TB2::Mouse will be internal use only... with one hitch.
Please stop cc'ing my personal email address on this mailing list mail. I'm already a subscriber. It just pollutes my personal mail from friends folders. -- rjbs
Re: TB2::Mouse will be internal use only... with one hitch.
On Tue, Nov 29, 2011 at 10:33:42PM -0800, Michael G Schwern wrote: On 2011.11.29 9:49 PM, David E. Wheeler wrote: How much slower will this make running the core tests, since neither Mouse nor Mouse::XS will every be available there (during development, at core installation time). Doing some back of the envelope calculations, it looks like an extra minute and a half on my laptop. I don't know how long core tests take right now. Running... use Test::More tests = 1; pass(ok); 100 times via prove... With 0.98: 2.2s With 1.5: 10s An extra 8 seconds per 100 tests. There's about 1100 core tests which use Test::More. 8 seconds x 11 is about 90 seconds. Divide by the number of CPU cores. Assuming one can hog them all, what probably matters is the duration of the IO::Compress tests. My laptop takes about 20 minutes to Configure, build and test the core. dromedary and various other multicore servers I have access to usually take about 5 minutes. Upshot - it saves a lot of time to hack locally, then rsync the code off to a different machine to actually run the complete tests. That's worst case. I can probably get compile time down at least 20ms which shaves off about 30 seconds. The IO::Compress tests being such a reliable serial bottleneck that I can set off a complete build and test run while writing this e-mail just to check that I had the right distribution, and it finishes before me :-) Nicholas Clark
Re: TB2::Mouse will be internal use only... with one hitch.
re: internal use What does internal define here? What are the boundaries of the space to which TB2::Mouse use is internal? In what scenarios do I have to write something that uses it? If I do that, am I likely using Mouse sugar? -- rjbs
Re: TB2::Mouse will be internal use only... with one hitch.
On 2011.11.30 7:20 AM, Ricardo Signes wrote: re: internal use What does internal define here? What are the boundaries of the space to which TB2::Mouse use is internal? Like any other internal use only .pm file in a CPAN module, it can only be used by the Test-Simple distribution (Test::Simple, Test::More, Test::Builder, TB2::Blah...). In what scenarios do I have to write something that uses it? You're patching Test-Simple. If I do that, am I likely using Mouse sugar? Yes. More than sugar, you're likely uhh... eating meat and potatoes? I don't know what the food analogy for roles and attribute default overrides would be. -- Alligator sandwich, and make it snappy!
Re: TB2::Mouse will be internal use only... with one hitch.
* Michael G Schwern schw...@pobox.com [2011-11-30T15:22:51] On 2011.11.30 7:20 AM, Ricardo Signes wrote: re: internal use What does internal define here? What are the boundaries of the space to which TB2::Mouse use is internal? Like any other internal use only .pm file in a CPAN module, it can only be used by the Test-Simple distribution (Test::Simple, Test::More, Test::Builder, TB2::Blah...). In what scenarios do I have to write something that uses it? You're patching Test-Simple. Okay. So, I want to write a third-party test output formatter that emits test results in the binary language of my water vaporators. I subclass some core formatter with use parent and add some methods or something? I want to write a better Test::Foo library. I'm not using extends 'Tester' or something? The only case when the programmer needs to know about the Mouse underpinnings is when hacking on the dist itself, not not ever reasonable extensions? -- rjbs
TB2::Mouse will be internal use only... with one hitch.
After the discussion, some pondering and hearing from Goro, I've decided that TB2::Mouse will be marked for internal use only. 1. People are uncomfortable that I'm shipping a copy of Mouse::Tiny, let alone making it public. 2. If it's private now, it can be made public later. Can't do it the other way around. 3. We don't need it for stable. 4. Mouse is a very easy dependency. It has no dependencies and can work without a compiler. There's not much value in providing a bundled copy. They can just depend on Mouse. 5. Goro wants it that way. Except there's a problem. In order to properly subclass a TB2 module your subclass must use TB2::Mouse. You can't use Mouse. For example. package My::TAP::Formatter; use Mouse; extends 'TB2::Formatter::TAP::v13'; has '+show_tap_version' = default = 0; This doesn't work. Mouse doesn't see the superclass's attributes because they were declared by a different namespace, TB2::Mouse. The subclass must use TB2::Mouse if it wants to override attributes. I hadn't realized that. It also must use TB2::Mouse if it wants to consume TB2 roles. This offers two choices: #1 Subclass authors will just have to deal. #2 TB2::Mouse is available IF AND ONLY IF you are subclassing or using a role. #1 isn't much different from the status quo of subclassing a non-Mo[ou]se Perl 5 OO module... except for the problem of roles. #2 is effectively publishing it. This is not academic. TB2::Event and TB2::EventHandler are roles. Writing new Events and EventHandlers are the primary way to extend how TB2 works. They could be turned into classes, but that would make things more difficult to extend. There is a 3rd choice, which brings us full circle to where this discussion started. We write TB2::Object [1] to select load Mouse if its available, TB2::Mouse otherwise. That way TB2 classes are compatible with Mouse just in time. They also get a performance kick. The core gets the for internal use only marked TB2::Mouse as previously discussed. The examples in the TB2 documentation can be changed to always show them using Mouse, further distancing TB2::Mouse from user eyeballs who might want to abuse it. The end result is... 1. The core gets a shrouded copy of Mouse::Tiny, with different namespaces, as discussed at the beginning. 2. TB2 gets a performance kick once Mouse is installed. 3. Extension authors can use Mouse to subclass TB2 and consume TB2 roles as normal. 4. TB2 continues to be able to take full advantage of Mouse. Nobody needs to ever know there's a copy of Mouse::Tiny in there. Thoughts? [1] I'd probably reverse it so that TB2::Mouse is the selector and TB2::Object is the Mouse::Tiny copy, but I don't want to make the discussion more confusing than it is. -- s7ank: i want to be one of those guys that types s/jjd//.^$ueu*///djsls/sm. and it's a perl script that turns dog crap into gold.
Re: TB2::Mouse will be internal use only... with one hitch.
On 2011.11.29 9:49 PM, David E. Wheeler wrote: How much slower will this make running the core tests, since neither Mouse nor Mouse::XS will every be available there (during development, at core installation time). Doing some back of the envelope calculations, it looks like an extra minute and a half on my laptop. I don't know how long core tests take right now. Running... use Test::More tests = 1; pass(ok); 100 times via prove... With 0.98: 2.2s With 1.5: 10s An extra 8 seconds per 100 tests. There's about 1100 core tests which use Test::More. 8 seconds x 11 is about 90 seconds. That's worst case. I can probably get compile time down at least 20ms which shaves off about 30 seconds. -- 170. Not allowed to defect to OPFOR during training missions. -- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army http://skippyslist.com/list/
