On Mon, Dec 21, 2015 at 8:07 AM, Abigail <abigail@abigail.be> wrote: > > But that's not a new problem, isn't? Even without the proposed fix, if > Y uses "use X '/pattern/'" and X gets updated to roll its own exporting, > and you install the new X, your module Z will break. > > The problem here isn't a new feature to Exporter, it's X ditching Exporter. > It's subtle in that X's author thinks they can safely superset the prior strings-only Exporter::import API, without realizing that downriver users have started relying on a newer feature of Exporter that X doesn't actually require as a dependency. Unrelated side note on the Exporter::Renamed etc. ideas. What about something like this: use Exporter 3.1415 importplusplus => { -as => 'import' }; Demands the version that has the feature and then utilizes the new feature to get the better behavior imported as "import". No new module required. But I also agree with Abigail about how long opt-in can take. David -- David Golden <xdg@xdg.me> Twitter/IRC/Github: @xdgThread Previous | Thread Next