Hi Jens! I'd love to have a module providing an improved and modern interface to File::ShareDir and I think the entire community would greatly benefit from it - not just the toolchain. That said, I would rather see it in a new module than have it in File::ShareDir itself. Kinda like how nowadays I prefer Path::Tiny over File::Spec + Cwd (or even Path::Class).
Cheers, garu On Tue, May 5, 2015 at 2:35 PM Karen Etheridge <p...@froods.org> wrote: > 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 >>> >>> >> >
