Re: File::ShareDir - Outstanding modernization
Hi all, I re-ordered the quotes to avoid sending multiple replies but answer in order. 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). 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 ? I think so. Reason follows ... 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? The original File::ShareDir isn't that light. The reason for reworking File::ShareDir is the missing support for a real share concept which confuses more end-users. Many (but not even close to all) Experienced developers understand the pitfalls and manage to deal with that. So introducing the support as intended is from my point of view necessary, while supporting existing API. That's not bloated. 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 is the intension of this thread. First discussing design details - on a probably very abstract level. Depending on the discussion we might need a more details design discussion or we can directly move to code (in a branch!). This code sits at the very heart of the cpan, called directly by ExtUtils::MakeMaker. You're not talking about https://github.com/Perl-Toolchain-Gang/ExtUtils-MakeMaker/pull/21, do you? Am 06.05.2015 um 02:33 schrieb breno oainikus...@gmail.com: 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). We can talk about a simplified interface on top of such low-level classes. Maybe it is a sane proposal to avoid to much new public API but accessors for a module on top of this. Can you imagine creating a proposal for such a high-level module which maybe covers ShareDir and ConfigDir for eg. an CLI application like App::Math::Tutor and a Web-Application using templates (not design!) in share and a configuration in etc/ telling where the web-root is, the share-name (referring to my app_dir proposal). Cheers -- Jens Rehsack - rehs...@gmail.com
Re: File::ShareDir - Outstanding modernization
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
Re: File::ShareDir - Outstanding modernization
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
Re: File::ShareDir - Outstanding modernization
On 6 May 2015 at 12:33, breno oainikus...@gmail.com wrote: 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). There is still a need for a simple mechanism for hooking FSD from a 3rd party library without resorting to crazy hacks, and its conceivable that such functionality can in fact be added without need for radical modernization. I have two such modules that rely on said crazy hacks, but they shouldn't be broken even under moderate FSD changes. You could in fact implement the low level simple hook mechanism in such a way that anyone who wanted Sno's fancy FHS compliant directories could simply load a new module, and that new module would hook FSD in the right places to get the benefits. But either way, I really want to champion small, logical, obvious, and entirely uncomplicated simple steps to improve FSD itself slowly, and that any more radical changes should occur at the users discretion, not at FSDs. -- Kent *KENTNL* - https://metacpan.org/author/KENTNL
Re: File::ShareDir - Outstanding modernization
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
