But I suspect this may also be an XY Problem. Perhaps you can explain why you (think you) need this. A module shouldn't normally need to know the full filename of its caller. Looking at it another way, why can't the script use the more reliable FindBin to determine its own path, and then pass that as an argument to the module?

I have a module that outputs a hash of useful information. The info is embedded in the module DATA but it changes (annually I think). The info can be found online so I'm trying to figure out a sane mechanism to update it without having to reinstall the module.

In that case, I'd say the answer is: it depends. Is the data something that the module can download automatically, or does it need to be curated by hand? If it can be done automatically, one could consider caching it in a ~/.something directory. For system-wide installation, just as an example, Debian packages like tzdata store the zoneinfo in /usr/share.

While it might be possible, I'm not sure I would recommend storing the data alongside the module directly (i.e. in the same directory or even in its __DATA__ section) if one wants the data to be updatable independently of the module. The reason I think so is that the typical expectation of a Perl user / developer would be that the module directories are generally only affected by the installation of modules, and if the module were to change its own files that might lead to inconsistencies, e.g. if modules are re-installed.

With answers to the above questions, we could probably narrow down the suggestions even more.

Of course, if the data only changes once a year, I think it's also a reasonable idea to include the data in the module and release a new version of the module when the data changes.

Another point: I don't see why such a module would need to know its callers path? "The info is embedded in the module DATA" sounds like the module wants to modify its own code, not the caller's? A module can use __FILE__ to get its own filename, and if the @INC directory it is located in is an absolute path, __FILE__ should be an absolute path as well.

Is the data something that the module can download automatically, or does it need to be curated by hand? If it can be done automatically, one could consider caching it in a ~/.something directory.

The module can already download, parse and compare the old and new data to determine if there's an update. I can lose the DATA section and have the module install the data ~/.somewhere but that should be a place that is accessible to all users in any scenario (system, perlbrew, etc) who may run the module in a cross platform compliant manner; and that the module can write to. Is there even such a place?

Of course, if the data only changes once a year, I think it's also a reasonable idea to include the data in the module and release a new version of the module when the data changes.

It seems reasonable until I realized that checking for updated modules is probably not a very common activity among casual users of software. I could make the module expire by failing to run after a certain date, but that seems more evil than providing the (slightly) wrong data.

Another point: I don't see why such a module would need to know its callers path?

I was thinking about one way to do it, by invoking the module from the folder one wants the new data to reside, and then telling the module about it like:

[user@to] perl -MMy::Mod=:all -e 'update()'
[user@to] Update detected! File saved to /path/to/data
[user@to] perl -MMy::Mod=:all -e 'foobar(data=>"/path/to/data");baz()'
[download]

That would work but I don't like it because scripts and such would have to be changed too. It would be better if the module installed the data to some standard place and simply updated the data file:

[user@to] perl -MMy::Mod=:all -e 'update()'
[user@to] Update detected! Using new data...
[download]

Or better make the module remember things and check once a month or so:

[user@to] perl -MMy::Mod=:all -e 'foobar();baz()'
[user@to] Update detected! Using new data...
[download]

As you did intuit, it was a bad idea that inspired the OP node. ⛐

Thanks for helping!