I am not opposed in principle to redesigning File::ShareDir, but I want to be *very* clear about the proposed design changes, impact on various parts of the toolchain, and back-compatibility concerns before anything moves beyond the design phase. This code sits at the very heart of the cpan, called directly by ExtUtils::MakeMaker.
On Tue, May 5, 2015 at 6:14 AM, Olivier Mengué <olivier.men...@gmail.com> wrote: > Hi, > > Is it really necessary to introduce those new features (bloat?) in the > existing File::ShareDir ? > > Why not just fork and keep the original File::ShareDir light? > What problems would be solved if the new features you plan were added to > the existing File::ShareDir? Which existing application would benefit from > these change just by upgrading to that new File::ShareDir, without using > the new APIs? > > Olivier. > > 2015-05-04 16:34 GMT+02:00 Jens Rehsack <rehs...@gmail.com>: > >> Hi, >> >> initially planned being one big topic for my QAH attendance, but Murphy >> decided to keep me busy otherwise (broken car, for everyone who didn't >> recognize on QAH...). >> >> Well - things are settling meanwhile and I have a few moments to think >> about the tasks I missed to finish in Berlin. One is File::ShareDir. >> >> The intension is to let File::ShareDir get closer to File::ConfigDir >> (and later let File::ConfigDir steal some features from File::ShareDir). >> >> The longterm goal is having it behave a bit more like "share" is intended >> (read until end of mail - don't scream here). There is no plan to break >> backwards compatibility (and if it happens on accident, the intension is >> to fix it and hopefully detect before it happens). >> >> Back to ideas for File::ShareDir: >> >> 1) analogous to File::ConfigDir have a bunch of share-dir prefixes >> including existing prefixes (core_share_dir, site_share_dir, >> vendor_share_dir, ...) and new ones (system_share_dir, >> machine_share_dir, >> here_share_dir, ...). >> ==> here is can be sane to have plugins like >> https://metacpan.org/release/File-ConfigDir-Plack >> for $ENV based locations (eg. FOO_BASE) or framework related >> extension. >> 2) Upon the prefixes, the dist_dir(), module_dir() will calculate the >> Full Qualified Share Dir as requested. It'll very likely to have other >> preferences is prefix picking for legacy API and new API (-> 3) >> 3) introduce better accessors (dist_share_dir, module_share_dir, >> app_share_dir, >> dist_config_dir, module_config_dir, ...). >> >> The goal is allow a module access share-dirs from different applications >> (eg. templates to process) or let applications rely on different immutable >> files from several distributions (think LaTeX as an example). >> >> Cheers >> -- >> Jens Rehsack - rehs...@gmail.com >> >> >
