Thanks for the longer response.
On Sun, Aug 04, 2013 at 05:11:29AM -0400, Kenichi Ishigaki via RT wrote:
Show quoted text> This request is something different. What this means is, metrics authors/contributors should test their metrics if they work locally before releases, and if they don't work, metrics authors/contributors should add some flags for local users. That's too much.
I don't think it needs to be burdensome, if a few simple flags are invented
in advance that distinguish metrics between "you can run this locally" and
"no you can't". My proposal was the first attempt to do that, but I'm sure
something better and simpler can be thought of, from the perspective of
someone who understands the CPANTS service better. Can we try to find
something that works?
Show quoted text> In other words, this makes conflict to those versions of TK, and as I said elsewhere, making conflicts is not an option.
As the maintainer of TK, I have already said that it very much *is* an
option, and I even gave you the way to do it safely (to indicate to users
of older versions of TK that they need to update, after installing a new
MCA). You can't keep supporting all old versions of TK forever, or you'll
never be able to do anything new.
Earlier versions of TK hardcoded the list of metric names, and even
enforced that all these metrics even had to exist (by planning that number
of tests in Test::Builder). That was bad (or more charitably,
short-sighted), and that's been removed now, and I DO NOT ASK NOR EXPECT
that those versions of TK shall continue working, on this nor any future
version of MCA. Please do not add code into the modules themselves to keep
these versions working. It's much easier to put in some metadata into the
MCA dist to say "you have a new MCA and old TK - that combination won't
work. You MUST upgrade."
I'm trying to work *with you* on this to make everything better, not throw
up obstacles.
Show quoted text> As for TK, it's fine as long as it tests only applicable and available metrics. You don't need to remove it at all. However, note that it's basically your responsibility to choose applicable metrics for your users, and not to expose uncertain metrics for them.
That's what I'm trying to do. But because the metrics change over time, I
thought that deciding on a few simple categories up front, and classifying
all metrics with these, would be an easy way to prevent (most) cases of
breakage.
Show quoted text> That said, because of recent changes in TK that assumed core metrics should always be applicable locally, it's much harder to add more core metrics in MCK. So, it might possibly be reasonable to make MCK a bit more local files friendly (as long as it doesn't hurt performance).
> Anyway, you know, as there are much more to add (and many of them are from you :), don't try to make them harder to add. And as I said repeatedly, don't assume too much. Don't assume core metrics should be applicable to local users, or expected metrics are always available, or everything is sorted, or whatever. The more you assume, the less we can improve.
I don't want TK to block what you want to do with MCA, but if there are
simple ways of keeping everything working, I'd like to consider those options.
RT for rt.cpan.org