in reply to Re^4: Do modules know the callers full path?
in thread Do modules know the callers full path?

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.

Replies are listed 'Best First'.
Re^6: Do modules know the callers full path?
by Anonymous Monk on Feb 17, 2023 at 15:48 UTC
      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()'
    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...
    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...
    As you did intuit, it was a bad idea that inspired the OP node. ⛐

    Thanks for helping!

      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?
      That sounds more or less like a place where "everyone" can write to. Being a systems admin at my employer's, I can tell you sysadmins don't like such places.

      I think the most reasonable approach would be to explicitly ask (e.g. via Parameter) for the place to store this info, so that the users would then forward this to their sysadmin who then could set up a place readable to all, and schedule an update job (e.g. monthly, or some schedule to be suggested by you)