Front page | perl.qa |
Postings from November 2011
Re: Relying more on Mouse
From: David Golden
November 25, 2011 17:08
Re: Relying more on Mouse
Message ID: CAOeq1c9irtu897HYSR82z116gqHT=VqJTzgvjRO6+Qu1kHPQ4A@mail.gmail.com
On Fri, Nov 25, 2011 at 4:02 PM, Michael G Schwern <firstname.lastname@example.org> 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.