Open kentfredric opened 9 years ago
Fun things discovered while overhauling:
@INC
when File::ShareDir::Install doesn't load" ( Wasting effort )== It has a whole lot of shit it doesn't need, to install test files, because it hasn't worked out how to use test files without installing them.
Next discovery: It doesn't really work on 5.005. File::ShareDir::Install doesn't work before 5.008!
As such, it has been broken on 5.006 since https://metacpan.org/diff/file?target=REHSACK/File-ShareDir-1.101/&source=ADAMK/File-ShareDir-1.03/
1.101 bundled File::ShareDir::Install 0.008
inc/File-ShareDir-Install/File/ShareDir/Install.pm
+package File::ShareDir::Install; + +use 5.008;
File::ShareDir::Install has required perl 5.008 since version 0.01
http://matrix.cpantesters.org/?dist=File-ShareDir-Install%200.10;maxver=1
Here's my basic proof of concept behind how I think it would be improved at present:
::Resolver
which has shims that produce good defaults
@RESOLVERS
global contains instances of resolves in preference-order.{dist,module}_*
are re-implemented as simple loops that interate @RESOLVERS
calling the respective functions and returning on the first match. https://github.com/kentfredric/File-ShareDir2/blob/master/lib/File/ShareDir2.pm#L128-L130 https://github.com/kentfredric/File-ShareDir2/blob/master/lib/File/ShareDir2.pm#L151-L162 https://github.com/kentfredric/File-ShareDir2/blob/master/lib/File/ShareDir2.pm#L183-L192 https://github.com/kentfredric/File-ShareDir2/blob/master/lib/File/ShareDir2/Resolver.pm https://github.com/kentfredric/File-ShareDir2/blob/master/lib/File/ShareDir2/Resolver/Perl.pm https://github.com/kentfredric/File-ShareDir2/blob/master/lib/File/ShareDir2/Resolver/Perl/Legacy.pm
This approach might be so far more complicated than necessary, but it should be flexible.
Things an extensible File::ShareDir should be able to do:
This is my discussion/mandate/idea for a File::ShareDir fork.
Shortlist of concerns.
Shortlist of intentions
File::ShareDir2
is the best I have atm )File::ShareDir
mechanics to support atypical locations.In depth
Bit Rot
Some of the bitrot applies to features that are needed, but nobody is adding yet.
Sno has made promises to add some, but they are not to be seen.
There are other bugs that appear to be still open after sitting in RT for 10 years with patches.
Maintainer Fear
There are concerns about the current and only semi-active maintainer caring about the right things, and there is demonstrated lack of taste.
Their priorities are at huge odds with what the CPAN community desire, and they are blocking on useful enhancements due to perceived requirements there is no evidence of anyone even needing, let alone asking for.
Namely, FHS compliance.
FHS compliance is something we've been debating heavily, and Sno as stated we need it, but there's no evidence that we need it. And we do needs a hooks architecture.
Blocking hooks to get FHS is just dubious priorities.
And even though in discussion I have been mostly reassured FHS compliance won't break compat and won't cause headaches, I have seen no code, and its been 7 months since there was any activity on the repository.
And given the nature of interactions on their other modules, there is a growing distrust that this maintainer is capable of maintaining things at a toolchain quality level.
These two reasons are the a priority reason to get a new namespace under the name of somebody who will gladly hand the firing orders to toolchain when its required. ( But are not the sole reasons ).
Dropping legacy layout support
Legacy layout support is simply causing more headaches for us than is necessary. No shared files have been written to that layout for several decades now, but the mechanisms that check for legacy layouts is still in place.
And those rules mean that any distribution that is even installed will false positive on
dist_dir()
, even when nodist_dir
has been installed. ( Because the legacy location happens to coincide with the XS binary dir )https://rt.cpan.org/Public/Bug/Display.html?id=86478
Given that this will be a new namespace, there will be not even legacy concerns here, as any distribution switching to the new namespace will be required to make sure they are using the new layout ( if in the event they were somehow managing to make the old one work ).
Additionally, with a hooks infrastructure, legacy support can be explicitly added and then turned on when somebody is 100% sure they need it. ( But it should be off by default ).
Extensibility / Hooks
The present mechanism of File::ShareDir is entirely
@INC
driven. There is no way to locally hook around this mechanism in code that already usesFile::ShareDir
to give a reasonable result.my own
Test::File::ShareDir
hacks around this at present using a lot of dark magic, namely, it creates a temporary directory that mocks the layout File::ShareDir looks for in@INC
, and then pushes that share directory into@INC
.This proves to be utterly useless with things that need the content of an overloaded share directory to have bi-directional changes without having to cycle the program ( for instance, a web app with resources in share/ will have to restart the server to get new shared content under Test::File::ShareDir ).
And you can't even hack around it by putting coderefs in @INC, because that also doesn't work:
https://metacpan.org/source/REHSACK/File-ShareDir-1.102/lib/File/ShareDir.pm#L186
And really can't be expected to work based on the way normal coderefs in @INC function.
My idea is to have a stack of resolvers, all stored in
@File::ShareDir2::HOOKS
, with the default node being a @INC traverser that uses the "new" mechanics.A legacy resolver can then be
push @File::ShareDir2::HOOKS, $resolver
and fallback mechanics can be observed.A localised resolver can then be
unshift @File::ShareDir2::HOOKS, $resolver
and take precedence over other resolvers.And in the exceedingly rare case FHS based resolvers are actually useful, one of those can be placed wherever in the hooks list is necessary, and end users can add it / nuke it based on need.