NAME
Devel::Deprecations::Environmental - deprecations for your code's surroundings
DESCRIPTION
A framework for managing deprecations of the environment in which your code runs
SYNOPSIS
This will load the Devel::Deprecations::Environmental::Plugin::Int32 plugin and emit a warning if running on a 32 bit system:
use Devel::Deprecations::Environmental qw(Int32);
This will start warning about an impending deprecation on the 1st of February 2023, upgrade that to a warning about being unsupported on the 1st of February 2024, and upgrade that to a fatal error on the 1st of February 2025:
use Devel::Deprecations::Environmental
Int32 => {
warn_from => '2023-02-01',
unsupported_from => '2024-02-01',
fatal_from => '2025-02-01',
};
This will always warn about 32 bit perl or a really old perl:
use Devel::Deprecations::Environmental
OldPerl => { older_than => '5.14.0', },
'Int32';
INCOMPATIBLE CHANGES
Version 1.000 used DateTime::Format::ISO8601 for parsing times provided as strings. This was removed in 1.100 as it had an unreasonable number of dependencies. As a result we now only support a subset of ISO 8601 formats, namely the sensible ones:
You can still pass in a DateTime object if you wish, and so can use DateTime::Format::ISO8601 yourself to construct them from some crazy involving week numbers if you really want.
DEPRECATION ARGUMENTS
Each deprecation has a name, which can be optionally followed by a hash-ref of arguments. All deprecations automatically support:
- warn_from
-
The time at which to start emitting warnings about an impending deprecation. Defaults to the moment of creation,
'1970-01-01'
(in general the accepted date format is YYYY-MM-DD followed by an optional space or letter T and HH:MM:SS). You can also provide this as a DateTime object.This must be before any of
unsupported_from
orfatal_from
which are specified. - unsupported_from
-
The time at which to start warning harder, when something is no longer supported. Defaults to
undef
, meaning "don't do this".This must be before
fatal_from
if that is specified. - fatal_from
-
The time after which the code should just
die
. Defaults toundef
, meaning "don't do this".
Of those three only the most severe will be emitted.
Arguments with names beginning with an underscore are reserved for internal use. Plugins can support any other arguments they wish.
CONTENT OF WARNINGS / FATAL ERRORS
The pseudo-variables $date
, $filename
, $line
, and $reason
will be interpolated.
$date
will be From $unsupported_from:
or From $fatal_from:
(using whichever is earlier) if one of those is configured.
$filename
and $line
will tell you the file and line on which Devel::Deprecations::Environmental
is loaded.
$reason
is defined in the plugin's reason()
method.
Initial warning
Deprecation warning! ${date}In $filename on line $line: $reason\n
"Unsupported" warning
Unsupported! In $filename on line $line: $reason\n
Fatal error
Unsupported! In $filename on line $line: $reason\n
FUNCTIONS
There are no public functions or methods, everything is done when the module is loaded (specifically, when its import()
method is called) with all specific deprecations handled by plugins.
WRITING YOUR OWN PLUGINS
The Devel::Deprecations::Environmental::Plugin::*
namespace is yours to play in, except for the Devel::Deprecations::Environmental::Plugin::Internal::*
namespace.
A plugin should inherit from Devel::Deprecation
, and implement the following methods, which will be called as class methods. Failure to define either of them will result in fatal errors. They will be passed the arguments hash-ref (with warn_from
, unsupported_from
, and fatal_from
removed):
- reason
-
Returns a brief string explaining the deprecation. For example "32 bit integers" or "Perl too old".
- is_deprecated
-
This should return true or false for whether the environment matches the deprecation or not.
FEEDBACK
I welcome feedback about my code, including constructive criticism, bug reports, documentation improvements, and feature requests. The best bug reports include files that I can add to the test suite, which fail with the current code in my git repo and will pass once I've fixed the bug
Feature requests are far more likely to get implemented if you submit a patch yourself, preferably with tests.
SOURCE CODE REPOSITORY
git://github.com/DrHyde/perl-modules-Devel-Deprecations.git
SEE ALSO
Devel::Deprecate - for deprecating parts of your own code as opposed to parts of the environment your code is running in;
AUTHOR, LICENCE and COPYRIGHT
Copyright 2023 David Cantrell <david@cantrell.org.uk>
This software is free-as-in-speech software, and may be used, distributed, and modified under the terms of either the GNU General Public Licence version 2 or the Artistic Licence. It's up to you which one you use. The full text of the licences can be found in the files GPL2.txt and ARTISTIC.txt, respectively.
CONSPIRACY
This module is also free-as-in-mason software.