Bug #95721 for File-ShareDir: [Feature request] Add official way to override share resoluion

Sat May 17 01:08:49 2014 KENTNL [...] cpan.org - Ticket created

Subject:

[Feature request] Add official way to override share resoluion

I've a few modules that are reasonbly well used that rely on tricking File::ShareDir into incorporating its things.

For instance, Test::File::ShareDir has to copy the source directory tree into a tempdir and stuff that directory in @INC to coax File::ShareDir into seeing its contents.

And this is not desirable for users who want to have a sharedir in their source tree and want to be able to run a catalyst server from their source tree and be able to update the static content in their /share/ directory and have catalyst refresh it.

I could be monkey patching File::ShareDir dynamically to do this, but that solution is worse than the disease.

My simple proposal would be as follows:

For both _dist_dir and _module_dir , have a hash for each:

our %File::ShareDir::DISTS
our %File::ShareDir::MODULES

and fast-resolve to those paths if they're in the hash.

For instance:

sub module_dir {

my $module = _MODULE(shift);

my $dir;

# Check the Hash
return $MODULES{$module} if exists $MODULES{$module};

# Try the new version

$dir = _module_dir_new( $module );

return $dir if defined $dir;

# Fall back to the legacy version

return _module_dir_old( $module );

}

This will ensure that behaviour will be retained for all sharedirs that are not explicitly indicated, while doing what is desired for the ones that are.

Sat May 17 05:45:48 2014 REHSACK [...] cpan.org - Correspondence added

RT-Send-CC:

ether [...] cpan.org

Thanks for the ticket as reminder, too. But let us avoid splitting argues, please let us use https://github.com/perl5-utils/File-ShareDir/pull/3 or this queue. Decide which one you like to prefer and add an appropriate comment to the other queue.

Sat May 17 05:45:49 2014 The RT System itself - Status changed from 'new' to 'open'

Sat May 17 07:55:07 2014 KENTNL [...] cpan.org - Correspondence added

I opened this bug first and this location was chosen because the metadata on the release still implies "bugs => rt".

Though I'm quite happy to keep it focused on the pull req, esp as RT is not so useful for dealing with PRs.