On Fri, Nov 25, 2011 at 4:02 PM, Michael G Schwern <schw...@pobox.com> 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" (or similar generic name) with an explicit "internal use only" disclaimer. Then anyone else who uses it knows the risk. -- David
