Re: Relying more on Mouse
> From: Michael G Schwern >Let's keep our heads. The whole argument against TB2::Mouse is predicated on >the idea that shipping TB2::Mouse in the core MIGHT cause future maintenance >hassle for p5p. If the alternatives will cause EVEN MORE maintenance hassle >for p5p and/or CPAN authors... we should just ship TB2::Mouse. Rename TB2::Mouse to something like TB2::_U_R_A_MORON_FOR_USING_THIS_ and I think the problem will take care of itself. Note: I'm not saying Schwern is a moron! I'm saying that if anyone dares to use TB2::Mouse with the above name, they'll definitely think twice. Cheers, Ovid -- Live and work overseas - http://overseas-exile.blogspot.com/ Buy the book - http://www.oreilly.com/catalog/perlhks/ Tech blog - http://blogs.perl.org/users/ovid/ Twitter- http://twitter.com/OvidPerl/
Re: Relying more on Mouse
Once again, I would like to rein this all in. Employing a counter-factual, the WORST CASE is that p5p has to ship a single 110K file which they never have to touch themselves. I am unable to get excited over the consequences. Let's keep our heads. The whole argument against TB2::Mouse is predicated on the idea that shipping TB2::Mouse in the core MIGHT cause future maintenance hassle for p5p. If the alternatives will cause EVEN MORE maintenance hassle for p5p and/or CPAN authors... we should just ship TB2::Mouse. On 2011.11.25 5:07 PM, David Golden wrote: > On Fri, Nov 25, 2011 at 4:02 PM, Michael G Schwern wrote: >> Keeping this all in perspective, TB2::Mouse is one 110K file (compressed down >> to 25K) with no POD. It's part of the Test-Simple distribution. p5p has to >> do NO EXTRA WORK AT ALL to include or maintain it. It just comes with >> Test-Simple like any other .pm file in Test-Simple. >> >> If I didn't bring it up, nobody would know it was there. Think about that. > > That sounds oddly like "security through obscurity" except it's > "compatibility through obscurity". :-) Someone always finds these > things out and then relies on them and then claims the need for > ongoing existence in core. Obscurity, documentation (or lack thereof) and social contract is how Perl enforces encapsulation. Whether we like it or not. Perl doesn't have an infatuation with enforced privacy. It would prefer that you stayed out of its living room because you weren't invited, not because it has a shotgun” ―- Larry Wall People can (and do) rely on internal code and then want us to maintain compatibility. At some point, project willpower to enforce encapsulation has to win out. I quote Tom... You are wicked and wrong to have broken inside and peeked at the implementation and then relied upon it. -- tchrist in <31832.969261130@chthon> Some careful and B documentation in TB2::Mouse can make this point even more clear. At some point, users take responsibility for ignoring the clearly marked warning signs. https://twimg0-a.akamaihd.net/profile_images/63014578/Crocodiles.jpg > As the current maintainer of Parse::CPAN::Meta -- which *is* an exact > copy of YAML::Tiny with a quick paint job (*cough* DZP::Doppelgaenger > *cough*), I'm sensitized to the issues, that's all. Roger. >> The real problem is how does Test::More depend on a non-core CPAN module >> without having a dependency on a non-core CPAN module? One which uses >> Test::More. That problem always remains. Test::More has it. MakeMaker has >> it. And the simple answer is bundling. > > I don't follow. I was speaking to the suggestions to use Role::Tiny or Object::Tiny or Role::Basic instead of a copy of Mouse::Tiny. They all present the same problem as TB2::Mouse. But you bring up some other scenarios while I'll address... > The only things that need to be in core (or need to > be bundled with a CPAN release) are modules sufficient to get a CPAN > client to deal with build_requires (and eventually test_requires). ...and the modules CPAN clients depend on. Very important. ...and the dependencies for everything else we currently ship in core. I would so love if the "only stuff for CPAN" policy was real and retroactive, but it is not. > Test::Hoopy can depend on Test::More 2 and core can have Test::More > 0.99 and CPAN clients will deal. You've already talked about a non > Test-More framework to test TB2, so you've already eliminated that > element of bootstrapping. Here's an example I hope will clarify. 1. CPAN-Meta's tests rely on Test::More. (they do) 2. CPAN-Meta is shipped with the core. (it is) 3. The next version of CPAN-Meta (knowingly or not) relies on a Test::More 1.5.x feature or bug fix in its tests. In order to ship CPAN-Meta, p5p has these options... 1. The core ships with Test::More 1.5.x. 2. CPAN-Meta is forced to downgrade their tests to only use 0.9x features. 3a. CPAN-Meta is forced to downgrade their tests to only use t/test.pl and copy t/test.pl into their CPAN distribution. 3b. Same as 3a, but we fork t/test.pl and make it available is an independent test library... and then ship it with the core. 4. p5p maintains a patched version of CPAN-Meta. 5. p5p stops running CPAN-Meta's tests as part of the build process. I think you'll agree, upgrading Test::More and accepting a single extra file that requires no extra maintenance is the approach with the most flexibility and least hassle for p5p and dual-life modules. This can happen to any module in cpan/ and dist/ http://cpansearch.perl.org/src/SHAY/perl-5.15.5/cpan/ http://cpansearch.perl.org/src/SHAY/perl-5.15.5/dist/ >> BTW What are those downstream maintenance costs? > > Someone ignores the "internal" nature of TB2::Mouse, sees that it's in > corelist, and writes something that depends on it. Later, you switch > to something else, or TB2::Mouse is no longer used by Test::More, or > you get hit by a bus
Re: Relying more on Mouse
On Fri, Nov 25, 2011 at 4:02 PM, Michael G Schwern wrote: > Keeping this all in perspective, TB2::Mouse is one 110K file (compressed down > to 25K) with no POD. It's part of the Test-Simple distribution. p5p has to > do NO EXTRA WORK AT ALL to include or maintain it. It just comes with > Test-Simple like any other .pm file in Test-Simple. > > If I didn't bring it up, nobody would know it was there. Think about that. That sounds oddly like "security through obscurity" except it's "compatibility through obscurity". :-) Someone always finds these things out and then relies on them and then claims the need for ongoing existence in core. > This discussion is EXACTLY THE SAME if TB2 were using Role::Tiny or > Role::Basic or any other CPAN module which is not currently core. Agreed. I'm having two separate thought-streams. First is "do non Mouse things get you 80% of what you need without the speed hit" and the answer seems to be "no". Second is "is it good policy to add clones of CPAN modules under another name"? As the current maintainer of Parse::CPAN::Meta -- which *is* an exact copy of YAML::Tiny with a quick paint job (*cough* DZP::Doppelgaenger *cough*), I'm sensitized to the issues, that's all. > The real problem is how does Test::More depend on a non-core CPAN module > without having a dependency on a non-core CPAN module? One which uses > Test::More. That problem always remains. Test::More has it. MakeMaker has > it. And the simple answer is bundling. I don't follow. The only things that need to be in core (or need to be bundled with a CPAN release) are modules sufficient to get a CPAN client to deal with build_requires (and eventually test_requires). Test::Hoopy can depend on Test::More 2 and core can have Test::More 0.99 and CPAN clients will deal. You've already talked about a non Test-More framework to test TB2, so you've already eliminated that element of bootstrapping. > BTW What are those downstream maintenance costs? Someone ignores the "internal" nature of TB2::Mouse, sees that it's in corelist, and writes something that depends on it. Later, you switch to something else, or TB2::Mouse is no longer used by Test::More, or you get hit by a bus and the next maintainer switches to TB2::Hamster. Then someone complains "TB2::Mouse was in core! You have to have a deprecation cycle", etc. None of these are impossible to solve, but with the deprecation policy in flux, I'd be nervous to add anything that might have to be maintained for a long time by *someone* whether or not that is *you*. Personally, I'm a "tough love" person on p5p. I'm relatively happier to break stuff and tell people to test their code and don't upgrade Perl if you don't like the new version. But there are others who don't and the vision that Jesse laid out implies that "use v5.XX" might mean that it should be honored by v5.30. Meaning "use v5.18" requires having the same copy of TB2::Mouse that was available in v5.18 years and years from now -- albeit with any security bug fixes that might appear. I hope that Rik clarifies that promise to something more manageable and it's an unlikely case, but the risk is there. > Anyhow, they would be in violation of the documentation (which would be > written in bold neon on the first page) and not supported. I *would* include just enough Pod to get an abstract line that says "for internal use only". I would also encourage you to call it something other than TB2::Mouse. TB2::Object or whatever. For the same reasons that Parse::CPAN::Meta isn't Parse::YAML::Tiny or whatever else it could have been called. Just don't imply Mouse. "It's just a black box. Naughty user, please go away!" Etc. > It won't work for the simple reason that if any dual-life CPAN module decides > to use a feature or bug fix of Test::More 1.5.0 then it can't be cored. The > forward dependency march will drag it in. We live in that world already, but with perl features. Which is why toolchain development sometimes sucks. > It also means the perl core gets no bug fixes and no feature enhancements. > Holding it back in the core is just YET ANOTHER immediate upgrade > that's necessary after a fresh perl install. C.f. Task::Kensho. The community has already decided that core Perl isn't enough for real tasks. Ditto "Bundle::CPAN" for that matter. > If I didn't point it out, nobody would have known it was there. I'd rather have the discussion up front and reach consensus than find something implemented that we regret later. Not a core example, but "PERL_CPANPLUS_IS_RUNNING" having to be set in CPAN.pm and cpanm is one of those examples of things where someone's bright idea has led to cruft that we'll be living with in every CPAN client for decades. It was a bright idea that made things easier for Module::Install... but with hugely annoying downstream impacts. Net -- I'd run this explicitly past Rik (if he's not following along), but I'm supportive if the answer is "TB2::Object
Re: Relying more on Mouse
On 2011.11.25 3:04 PM, chromatic wrote: > On Friday, November 25, 2011 at 01:02 PM, Michael G wrote: >> We did it once with Test::Harness::Straps, though not nearly that well >> thought out, and it worked. > > Do you know anyone (besides me) who used it? I know I dealt with some DarkPAN users, but it's been so long I can't enumerate them. There's a handful on CPAN and in Google Code Search. https://metacpan.org/requires/module/Test::Harness::Straps http://www.google.com/codesearch#search/&q=%22use%20Test::Harness::Straps%22%20lang:perl&type=cs I agree it's not a scale test, but the mechanism worked. >> I do see a work around. Document that TB2::Mouse can be used, but you MUST >> add it as a dependency anyway. > > I hate to see the core (even implicitly) blessing Yet Another Object System. The core hasn't blessed any object system, directly or indirectly, unless you count the ad hoc messes previously cobbled together in the old OO tutorials. So it's hard to say "yet another". But I'm willing to say whatever they come up with in the future is going to look an awful lot like Moose. One of the major problems with including a module in the core is its *implicit* blessing. The core never said anything about whether a core module was blessed or better than others, users just assumed it. With TB2::Mouse, we have a chance to *explicitly* state the terms. If it's going to be for internal TB2 use only, we can state that. If it's going to be a stop-gap until a better OO system is core, we can state that. Those old OO tutorials are going away BTW. Moose, Mouse, Class::Accessor, Object::Tiny and Role::Tiny are all talked about in the new OO tutorial. http://cpansearch.perl.org/src/SHAY/perl-5.15.5/pod/perlootut.pod >> It won't work for the simple reason that if any dual-life CPAN module >> decides to use a feature or bug fix of Test::More 1.5.0 then it can't be >> cored. > > I'm also little enamored of pre-emptive coring. > > I'd like to see TB2 *used* outside of bootstrapping for a while first before > considering it a replacement for TB. There's some sort of misunderstanding or terminology mix up. The TB2 modules cannot be separated from Test::More any more than Test::Builder can. Test::Builder is using the TB2 infrastructure. Even if I chucked out the whole event system, Test::Builder would still make use of TB2::Formatter. I expect TB2 to go through an alpha period for a while. The current formal alpha phase for compatibility with existing code, make sure nothing breaks. Then a post-stable 1.5.0 phase where the TB2 interfaces are considered unstable, so we can knock them around. I'm sure there will be plenty of little changes. People can try TB2 out NOW and give feedback. Even if it's "I don't understand this, the docs for X suck". That is useful! I'm so deep in the design its hard for me to see that. There are plenty of modules which could be rewritten right now far easier using TB2. Off the top of my head... Test::SharedFork Test::Aggregate Test::NoWarnings Test::Class Test::Block Fennic Test::DebugOnFail (that's in the examples directory) And I'm still waiting on someone taking a stab at an alternative output format like JUnit or JSON. -- I am somewhat preoccupied telling the laws of physics to shut up and sit down. -- Vaarsuvius, "Order of the Stick" http://www.giantitp.com/comics/oots0107.html
Re: Relying more on Mouse
On Friday, November 25, 2011 at 01:02 PM, Michael G wrote: > We did it once with Test::Harness::Straps, though not nearly that well > thought out, and it worked. Do you know anyone (besides me) who used it? > I do see a work around. Document that TB2::Mouse can be used, but you MUST > add it as a dependency anyway. I hate to see the core (even implicitly) blessing Yet Another Object System. > It won't work for the simple reason that if any dual-life CPAN module > decides to use a feature or bug fix of Test::More 1.5.0 then it can't be > cored. I'm also little enamored of pre-emptive coring. I'd like to see TB2 *used* outside of bootstrapping for a while first before considering it a replacement for TB. -- c
Re: Relying more on Mouse
Keeping this all in perspective, TB2::Mouse is one 110K file (compressed down to 25K) with no POD. It's part of the Test-Simple distribution. p5p has to do NO EXTRA WORK AT ALL to include or maintain it. It just comes with Test-Simple like any other .pm file in Test-Simple. If I didn't bring it up, nobody would know it was there. Think about that. This discussion is EXACTLY THE SAME if TB2 were using Role::Tiny or Role::Basic or any other CPAN module which is not currently core. On 2011.11.25 3:53 AM, David Golden wrote: > To be clear -- I'm not (yet) saying that TB2 should absolutely roll > it's own OO, but I am concerned about hiding yet another copy of a > perfectly decent CPAN module so that we can avoid saying that we're > including another CPAN module in core. It's seductively easy to get > the benefits *now* during the development of TB2, but there are > downstream maintenance costs that we shouldn't discount lightly. That is only a tangential problem. The real problem is how does Test::More depend on a non-core CPAN module without having a dependency on a non-core CPAN module? One which uses Test::More. That problem always remains. Test::More has it. MakeMaker has it. And the simple answer is bundling. BTW What are those downstream maintenance costs? >> Also one of the side benefits of shipping TB2::Mouse is now other Test >> modules >> can rely on it getting the benefit of a fully operational OO system without >> adding further dependencies. > > And potentially *other*, non-test modules could start doing so too. Disallowing non-Test modules is not strictly necessary, it's just something I have in my head to rein this in a bit. I don't think it changes anything. Anyhow, they would be in violation of the documentation (which would be written in bold neon on the first page) and not supported. p5p doesn't always toe that line, but that's their problem. > Is there a guarantee that TB2::Mouse will always be in core (short of > a deprecation cycle)? Would it have to be available "forever" under > "use v5.18"? I'm very leery of adding more core modules when the core > policy around deprecation or lack thereof is in flux. If it's documented, then yes. See above about it being a single file with no extra support costs for p5p. I do see a work around. Document that TB2::Mouse can be used, but you MUST add it as a dependency anyway. That way when we do remove it from the core (and I do agree, it would be nice if we could) then it can be put on CPAN and slurped in like anything else. We did it once with Test::Harness::Straps, though not nearly that well thought out, and it worked. > [ Social hack: include TB2::Mouse but mark it "deprecated" from the > start. :-) ] That would be "for internal use only" and lacking documentation like all the other "for internal use only" .pm files already in core and other CPAN modules. The "everyone else gets an OO framework" part of this plan is just gravy. Right now it's not documented at all, so anyone using it has violated encapsulation and gets no support. > If I had my druthers, I'd like to see Stevan's core MOP work finished, > then I'd like to see a powerful, minimalist object system on top of > *that* built for inclusion in core, then I'd like to see core modules > gradually migrating to that. And I'd like a pony, too. Throw in a time machine so we can all fast forward three years to that version of the future. Wait... eleven years! Gotta wait for all those versions of Perl that don't have a MOP to end-of-life! :-/ > Maybe the related, fundamental question is whether TB2 itself needs to > be in core -- or, if so, *when* it needs to be in core. Maybe core is > just fine with Test::More as is and anyone needing more powerful > testing frameworks can install TB2 from CPAN. (Ditto for any new test > modules that are written that rely on TB2.) Eventually, when TB2 is > well proven on CPAN and the core offers the kind of MOP that TB2 > needs, then it can migrate in. It won't work for the simple reason that if any dual-life CPAN module decides to use a feature or bug fix of Test::More 1.5.0 then it can't be cored. The forward dependency march will drag it in. It also means the perl core gets no bug fixes and no feature enhancements. Unless they want to maintain their own fork, which I sure as hell am not. And that IS an extra maintenance load for p5p. As TB2 is a pretty radical internals restructuring, and I expect new and existing Test modules will want to start using those internals, and people will want to start using those new versions, Test::More 1.5.0 will be required. Holding it back in the core is just YET ANOTHER immediate upgrade that's necessary after a fresh perl install. While we might debate the utility of having certain modules in the core, modules which help install other modules have always been in that set. The test framework used by 80% of CPAN is squarely in that category. Should it be thrown ou
Re: Relying more on Mouse
On Thu, Nov 24, 2011 at 4:23 PM, Michael G Schwern wrote: > I don't think cobbling together an OO system from bits and bobs, and then > relying on it, makes more sense than using a fully baked one Of course, that pretty much describes Perl OO in a nutshell until Moose/Class::MOP came along. And it describes pretty much how every other core module does OO. (With the possible exception of CPANPLUS, which dragged Object::Accessor into core with it.) To be clear -- I'm not (yet) saying that TB2 should absolutely roll it's own OO, but I am concerned about hiding yet another copy of a perfectly decent CPAN module so that we can avoid saying that we're including another CPAN module in core. It's seductively easy to get the benefits *now* during the development of TB2, but there are downstream maintenance costs that we shouldn't discount lightly. > Also one of the side benefits of shipping TB2::Mouse is now other Test modules > can rely on it getting the benefit of a fully operational OO system without > adding further dependencies. And potentially *other*, non-test modules could start doing so too. Is there a guarantee that TB2::Mouse will always be in core (short of a deprecation cycle)? Would it have to be available "forever" under "use v5.18"? I'm very leery of adding more core modules when the core policy around deprecation or lack thereof is in flux. [ Social hack: include TB2::Mouse but mark it "deprecated" from the start. :-) ] If I had my druthers, I'd like to see Stevan's core MOP work finished, then I'd like to see a powerful, minimalist object system on top of *that* built for inclusion in core, then I'd like to see core modules gradually migrating to that. And I'd like a pony, too. Maybe the related, fundamental question is whether TB2 itself needs to be in core -- or, if so, *when* it needs to be in core. Maybe core is just fine with Test::More as is and anyone needing more powerful testing frameworks can install TB2 from CPAN. (Ditto for any new test modules that are written that rely on TB2.) Eventually, when TB2 is well proven on CPAN and the core offers the kind of MOP that TB2 needs, then it can migrate in. -- David
