Re: Any::Moose deprecation

[Niko Tyni <ntyni@debian.org>]

On Fri, Nov 25, 2016 at 03:01:25PM +0100, Alex Muntada wrote:
> gregor herrmann:

> > Just commenting out the deprecation warning in Any::Moose would be
> > easy, although it feels a bit cheap. But maybe there's an argument to
> > be made for it as the target audience for the warning is not the
> > average user of some automatically installed Debian package but the
> > authors of the rdeps?
> 
> I think this is the cleanest fix for Debian users and package
> maintainers in the short term.
> 
> On the other hand, it's worth noticing that the warning can be
> disabled for the caller's scope with «no warnings 'deprecated';»
> (it would a quick fix for upstream authors of reverse depends):

Thanks for the comments.

It seems to me that the warning has several somewhat different audiences
here:

 A) upstream authors of modules or applications using Any::Moose

 B) authors of local code that uses libany-moose-perl directly

 C) authors of local code that uses libany-moose-perl indirectly via
    other packaged modules

 D) users of packaged applications using libany-moose-perl
    (directly or indirectly)

A) is not our domain, assuming they don't use the packaged modules anyway.

B) is a group that we should notify about the deprecation, so they know
they need to migrate their code.

C) I'm not sure about; if the modules using Any::Moose get fixed at some
point, they presumably don't care, but at some point they should start
looking at alternatives. Maybe that point has arrived?

D) is the group that is not "empowered" to do anything about this other
than file bugs/patches, so we shouldn't bother them with the warnings.

Patching the warning away globally would leave both B) and C) unnotified
that they need to migrate their code. This doesn't seem optimal.

Adding "no warnings 'deprecated'" to the libany-moose-perl rdep packages
would notify B) but still leaves C) unnotified.

Adding "no warnings 'deprecated'" only to packaged applications would
notify B) and C).

So it seems that the choice depends on whether we want to make authors
of local code that uses (for instance) Path::Dispatcher aware that
their dependency chain includes a deprecated module.

I note that disabling the warnings in many places is certainly more work
than just doing it once globally, so possibly all this is just not worth
it anyway?

Patching packages to use Moo (or whatever) does seem rather invasive
if it's not done upstream, but maybe there are cases where it's trivial
enough to be a viable option.

Apologies if I'm making simple things too complex here :)
-- 
Niko