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 <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.
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<VERY LOUD> 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 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 reject the "somebody might rely on it" argument wholly, especially if we
clearly post the terms in TB2::Mouse. At some point we have to enforce
clearly marked encapsulation.
You might not have spotted it in my reply to chromatic, but part of those
terms is that you must depend on TB2::Mouse as you would any CPAN module.
Then it can be removed from the core and Test-Simple distribution and put on
CPAN in its own distribution, like Test-Harness-Straps. This provides an
explicit means for people to rely on it AND for us to remove it from the core.
People will ignore this advice as well, but their mistake is mitigated by
adding a simple dependency when the time comes to remove TB2::Mouse.
"use 5.xx" involves documented features and perhaps areas which are a bit
wibbly on the details. I don't expect that it's supposed to be bug for bug
compatible, nor compatible with violations of big B<KEEP OUT> postings.
In short, I reject any argument predicated on "the user ignores the clearly
posted warnings". p5p might not, but I'm happy to allow them to take on an
extra problem for themselves.
>> 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.
If TB2::Mouse is for internal TB2 use only, I agree with caveats. There's
problems with completely denying these are Mo[ou]se objects. There's useful
meta things you can do if you know a class is Moose-based, and we'd be
throwing that away. The existing TB2 documentation is predicated on the idea
that the user can reference the Moose docs to understand how accessors and
attributes work. These can all be overcome, but that means more work and
maintenance and duplication... just the thing we're trying to avoid.
I would like it to be available for Test:: authors. "You depend on Test::More
>= 1.5.x, you also get a free object system!" This raises the bar of minimum
dependencies. It's right there, we need to ship it anyway, we might as well
let people use it.
>> 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.
"Make it suck more" isn't something I can get behind.
If this were Term::ANSIColor or Digest::MD5 or Parse::CPAN::Meta... something
only used in the core in a few places and fairly small... I'd understand.
This is a module that affects *every dual life module*. Not upgrading makes
every dual life maintainer's job harder. See argument at the top of this email.
>> 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.
See above, except it now makes every CPAN module maintainer's life harder, not
just the dual lifed ones.
>> 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.
Point of order, this has been discussed and posted in public and presentations
several times for over two years. I'm glad it's being discussed, and I fully
expected people to only pay attention once things stabilized, but I'm a little
miffed that it's come at this late stage after so much work has been done on
top of TB2::Mouse.
> 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.
I understand the concern, but I see nothing remotely like that possibility
here. Do you?
I've gone through some pain to separate TB2::Mouse from Mouse, internally and
externally, to avoid a conflict.
> 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.
Him and Goro have been CC'd several times. I'll ask directly for them to
weigh in.
--
31. Not allowed to let sock puppets take responsibility for any of my
actions.
-- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army
http://skippyslist.com/list/
