kentfredric
commented
9 years ago Fun things discovered while overhauling:
- Packs File::ShareDir::Install
- Also build/configure requires File::ShareDir::Install ( FUN! )
- Conditionally uses
@INCwhen File::ShareDir::Install doesn't load" ( Wasting effort ) - Fortunately, File::ShareDir::Install does not require File::ShareDir
- ..... Why does it do this?
- File ShareDir installs some files
- What files? Why?
- Test files.
- ....
== 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.
This is my discussion/mandate/idea for a File::ShareDir fork.
Shortlist of concerns.
Shortlist of intentions
File::ShareDir2is the best I have atm )File::ShareDirmechanics 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_dirhas 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
@INCdriven. There is no way to locally hook around this mechanism in code that already usesFile::ShareDirto give a reasonable result.my own
Test::File::ShareDirhacks 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, $resolverand fallback mechanics can be observed.A localised resolver can then be
unshift @File::ShareDir2::HOOKS, $resolverand 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.