Re: fetching asset files from github during installation of module from CPAN

The best way would be to include the files in the distribution itself - someone could install it from their own local CPAN mirror with no access to the internet. You can always try to fetch a newer version from github during the installation - File::Fetch is a core module that should do that. P5P might remove it from the core, though, so you could use HTTP::Tiny as a replacement.

($q=q:Sq=~/;[c](.)(.)/;chr(-||-|5+lengthSq)`"S|oS2"`map{chr |+ord
}map{substrSq`S_+|`|}3E|-|`7**2-3:)=~y+S|`+$1,++print+eval$q,q,a,
[download]

Comment on Re: fetching asset files from github during installation of module from CPAN Download Code

Replies are listed 'Best First'.
Re^2: fetching asset files from github during installation of module from CPAN by tmaly (Monk) on Mar 15, 2016 at 22:15 UTC
I was thinking of including the most recent version as of the date I publish the module to CPAN. Then I would want to attempt to try to fetch a newer version at installation time. I will give File::Fetch a shot. Thanks	[reply]
Re^3: fetching asset files from github during installation of module from CPAN by stevieb (Canon) on Mar 15, 2016 at 22:43 UTC
I'd go the route choroba stated, and wrap it into an early test in the test suite (`eval` to fetch). Perform a significant number of tests against the version that is bundled with the module, and then perform the same extensive tests against the new version before installing it, as to ensure you don't break functionality of the module with a new version of the updated files during your install. This way, by not doing it in `Makefile.PL` or something, if the fetch fails, or your unit tests don't pass on the new version of files, you can lean back on the existing bundled versions.	[reply] [d/l] [select]
Re^3: fetching asset files from github during installation of module from CPAN by MidLifeXis (Monsignor) on Mar 16, 2016 at 17:21 UTC
From a code review standpoint, I would reject the use of any installation that went outside of the code provided in the package at installation time, as this would provide a mechanism to identify users of the package inject some unknown, unreviewed chunk of code into the dev (prod - hopefully not) environment other creative attacks on an environment Not saying that this is your intent, but use of that would be shot down in a heartbeat under any cursory review here. --MidLifeXis	[reply]