Skip Menu |

This queue is for tickets about the File-ShareDir CPAN distribution.

Report information
The Basics
Id: 60431
Status: resolved
Priority: 0/
Queue: File-ShareDir

People
Owner: Nobody in particular
Requestors: w.phillip.moore@gmail.com (no email address)
Cc:
AdminCc:

Bug Information
Severity: Normal
Broken in: 1.02
Fixed in: 1.02



Subject: Support for objects in @INC
Adam et al -- This is not a bug report, but rather a request for a small new feature, and a patch that implements it. The current version searches for the share dir relative to the directories in @INC, and simply skips any references in @INC. This is perfectly reasonable behavior of course, and probably the only obvious thing to do with @INC entries that aren't strings. However, we're using some interesting infrastructure that leverages the @INC objects support, and the objects we create overload stringification to return the underlying directory they represent. The code's purpose is to provide an INC method that checks for file existence based on some cached data, thus avoiding filesystem I/O. The attached patch does two things. First of all, I refactored the @INC searching code into a single subroutine, and second, it simply does a directory test of the quoted entry. This allows the code to work with our objects (or anyone's object, if they just overload "" to return the directory), and I believe it should still skip other references just fine. Please let me know if this feature and patch acceptable to you. Thanks in advance, and all that....
Subject: File-ShareDir-1.02-INC-objects.patch
diff -r -u File-ShareDir-1.02/lib/File/ShareDir.pm File-ShareDir-1.02-INC-objects/lib/File/ShareDir.pm --- File-ShareDir-1.02/lib/File/ShareDir.pm 2010-03-17 21:31:04.000000000 -0400 +++ File-ShareDir-1.02-INC-objects/lib/File/ShareDir.pm 2010-08-13 18:28:08.000000000 -0400 @@ -176,18 +176,8 @@ 'auto', 'share', 'dist', $dist, ); - # Find the full dir withing @INC - foreach my $inc ( @INC ) { - next unless defined $inc and ! ref $inc; - my $dir = File::Spec->catdir( $inc, $path ); - next unless -d $dir; - unless ( -r $dir ) { - croak("Found directory '$dir', but no read permissions"); - } - return $dir; - } + return _search_inc_path( $path ); - return undef; } sub _dist_dir_old { @@ -198,18 +188,8 @@ 'auto', split( /-/, $dist ), ); - # Find the full dir within @INC - foreach my $inc ( @INC ) { - next unless defined $inc and ! ref $inc; - my $dir = File::Spec->catdir( $inc, $path ); - next unless -d $dir; - unless ( -r $dir ) { - croak("Found directory '$dir', but no read permissions"); - } - return $dir; - } + return _search_inc_path( $path ); - return undef; } =pod @@ -252,18 +232,7 @@ _module_subdir( $module ), ); - # Find the full dir withing @INC - foreach my $inc ( @INC ) { - next unless defined $inc and ! ref $inc; - my $dir = File::Spec->catdir( $inc, $path ); - next unless -d $dir; - unless ( -r $dir ) { - croak("Found directory '$dir', but no read permissions"); - } - return $dir; - } - - return undef; + return _search_inc_path( $path ); } sub _module_dir_old { @@ -344,19 +313,10 @@ 'auto', split( /-/, $dist ), $file, ); - # Find the full dir withing @INC - foreach my $inc ( @INC ) { - next unless defined $inc and ! ref $inc; - my $full = File::Spec->catdir( $inc, $path ); - next unless -e $full; - unless ( -r $full ) { - croak("Directory '$full', no read permissions"); - } - return $full; - } + my $dir = _search_inc_path( $path ) || + croak("Failed to find shared file '$file' for dist '$dist'"); - # Couldn't find it - croak("Failed to find shared file '$file' for dist '$dist'"); + return $dir; } =pod @@ -468,6 +428,28 @@ ##################################################################### # Support Functions +sub _search_inc_path { + + my $path = shift; + + # Find the full dir within @INC + foreach my $inc ( @INC ) { + # NOTE: This allows objects in @INC that provide the + # directory by overloading stringification, and still + # skips references correctly. + next unless -d "$inc"; + my $dir = File::Spec->catdir( $inc, $path ); + next unless -d $dir; + unless ( -r $dir ) { + croak("Found directory '$dir', but no read permissions"); + } + return $dir; + } + + return undef; + +} + sub _module_subdir { my $module = shift; $module =~ s/::/-/g;
Subject: Re: [rt.cpan.org #60431] Support for objects in @INC
Date: Tue, 17 Aug 2010 14:30:23 -0400
To: Phillip Moore via RT <bug-File-ShareDir [...] rt.cpan.org>
From: Jesse Vincent <jesse [...] fsck.com>
Show quoted text
> The current version searches for the share dir relative to the directories in @INC, and simply > skips any references in @INC. This is perfectly reasonable behavior of course, and probably > the only obvious thing to do with @INC entries that aren't strings. > > However, we're using some interesting infrastructure that leverages the @INC objects > support, and the objects we create overload stringification to return the underlying directory > they represent. The code's purpose is to provide an INC method that checks for file existence > based on some cached data, thus avoiding filesystem I/O.
That seems fairly specialized and overloaded stringification isn't a standard part of references/objects in @INC. This seems like something you might want in a custom subclass.
Subject: Re: [rt.cpan.org #60431] Support for objects in @INC
Date: Tue, 17 Aug 2010 15:59:01 -0400
To: bug-File-ShareDir [...] rt.cpan.org
From: Phillip Moore <w.phillip.moore [...] gmail.com>
Thanks for the quick response. I'd like to ask you to reconsider though, for the following reasons. First of all, File::ShareDir can't be sub-classed, since it's not an object oriented module. All of the methods are procedural, and there isn't even a single method that does the @INC searching, which is what you would need to override in a subclass. Using objects in @INC has been supported for quite some time, and while it is certainly true that the interface doesn't define any specific behavior for overloading, this patch at least makes it possible to use them, and still leverage File::ShareDir. We're leveraging some features of the perl core that are probably used very rarely, I think. For example, we're about to submit patches for the sitecustomize.pl mechanism, since it lacks any form of error checking. Clearly, very few people are actually using that feature. Similarly, using objects in @INC is a rarely used feature as well, so it's not surprising that modules like File::ShareDir don't support it. In this case, we're simply proposing to make it possible for the authors of @INC objects to leverage File::ShareDir by simply overloading stringification. This change is almost entirely backwards compatible I believe, and only serves to make File::ShareDir even more useful than it already is. The edge conditions which are not backwards compatible should hopefully be irrelevant, too. I expect that we'll find similar issues with other modules that directly inspect the contents of @INC, and we hope to improve the usability of objects in @INC by patching them, as well (if possible). Would you please reconsider accepting this patch, on the grounds that it makes @INC objects more useful? On Tue, Aug 17, 2010 at 2:31 PM, Jesse via RT <bug-File-ShareDir@rt.cpan.org Show quoted text
> wrote:
Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=60431 > > >
> > The current version searches for the share dir relative to the
> directories in @INC, and simply
> > skips any references in @INC. This is perfectly reasonable behavior of
> course, and probably
> > the only obvious thing to do with @INC entries that aren't strings. > > > > However, we're using some interesting infrastructure that leverages the
> @INC objects
> > support, and the objects we create overload stringification to return the
> underlying directory
> > they represent. The code's purpose is to provide an INC method that
> checks for file existence
> > based on some cached data, thus avoiding filesystem I/O.
> > > That seems fairly specialized and overloaded stringification isn't a > standard part of references/objects in @INC. This seems like something > you might want in a custom subclass. > >
Subject: Re: [rt.cpan.org #60431] Support for objects in @INC
Date: Wed, 18 Aug 2010 15:08:47 +1000
To: bug-File-ShareDir [...] rt.cpan.org
From: Adam Kennedy <adamkennedybackup [...] gmail.com>
From memory, the reason I didn't implement support for references in @INC is that (from my reading of the coderef behaviour) the @INC coderefs return filehandles to be read from. Many uses of File::ShareDir are not seeking to load a single file in this way, but are instead locating a root directory within which many dozens or hundreds of files may exist. Would this not mean that any such CODE reference @INC hooks could never have returned a file or directory name, as the code may not actually exist as files. The same seems to apply for objects in @INC, according to here anyway. http://perldoc.perl.org/functions/require.html The finding of a directory, or even a file name, does not seem to exist in the concept as documented. I'm loath in modules this low level to take actions without the blessings of #p5p. While you can't overload, one other option which is suitably evil given what you want is to use Hook::LexWrap. Your "sub-class" would load File::ShareDir, and then hijack the normal functions to replace them with your alternative behaviour. If the optimisation system in question will never go to CPAN, it is quite acceptable. If it is going to CPAN, it is reasonable as long as it is the only module that might over monkey-patch File::ShareDir in this way (which may not be an entirely unreasonable assumption). Adam K On 18 August 2010 04:28, Phillip Moore via RT <bug-File-ShareDir@rt.cpan.org> wrote: Show quoted text
> Tue Aug 17 14:28:12 2010: Request 60431 was acted upon. > Transaction: Ticket created by WPMOORE >       Queue: File-ShareDir >     Subject: Support for objects in @INC >   Broken in: 1.02 >    Severity: Normal >       Owner: Nobody >  Requestors: w.phillip.moore@gmail.com >      Status: new >  Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=60431 > > > > Adam et al -- > > This is not a bug report, but rather a request for a small new feature, and a patch that > implements it. > > The current version searches for the share dir relative to the directories in @INC, and simply > skips any references in @INC.  This is perfectly reasonable behavior of course, and probably > the only obvious thing to do with @INC entries that aren't strings. > > However, we're using some interesting infrastructure that leverages the @INC objects > support, and the objects we create overload stringification to return the underlying directory > they represent.  The code's purpose is to provide an INC method that checks for file existence > based on some cached data, thus avoiding filesystem I/O. > > The attached patch does two things.  First of all, I refactored the @INC searching code into a > single subroutine, and second, it simply does a directory test of the quoted entry.  This allows > the code to work with our objects (or anyone's object, if they just overload "" to return the > directory), and I believe it should still skip other references just fine. > > Please let me know if this feature and patch acceptable to you. > > Thanks in advance, and all that.... >
Subject: Re: [rt.cpan.org #60431] Support for objects in @INC
Date: Wed, 18 Aug 2010 11:40:25 -0400
To: bug-File-ShareDir [...] rt.cpan.org
From: Phillip Moore <w.phillip.moore [...] gmail.com>
The API that perl uses when searching @INC for a file to load via "use" or "require" is simple. The object must implement an INC method that returns a filehandle. However, that API is only used by use and/or require. In this case, your module is simply interpreting each @INC entry as a directory, and doing searches for pathnames relative to those directories. It's obvious that there's no way you can interpret a generic, non-blessed reference as a directory, so skipping them makes complete sense. What I'm proposing is a very simple way to interpret the blessed @INC entries that makes it *possible* for an object to be implemented that can satisfy perl's use/require API, and thus avoid a tremendous amount of needless filesystem I/O, and still be interpreted as a single directory by your code. Now, I would prefer that the documented API for objects in @INC included an optional method that returns the underlying directory, and then File::ShareDir would simply use this to support such objects. No such API exists, obviously, so I'm leveraging operator overloading to provide a simple way to extract the directory from my objects. At the end of the day, all I'm trying to do is incrementally improve the usefulness of objects in @INC by patching File::ShareDir to *allow* an object author to use this same mechanism to implement objects which can work with it. As currently implemented, you can only use File::ShareDir if you do not leverage this mechanism. My patch tries to build a small, simple bridge between your module and this somewhat arcane feature of perl. As for subclassing it with yet another layer of special module complexity, that's really overkill here. For my own, specific application, I can replace use of File::ShareDir with something trivial like: my $base_dir = dirname dirname $INC{ q{EFS/Deploy.pm} }; my $share_dir = qq{$base_dir/auto/share/dist/EFS-Deploy}; If I recall the convention off the top of my head. However, rather than just make my code work, I'm trying to extend File::ShareDir so that it can work with ANY code that is deployed using our system. If the patch isn't accepted, then it doesn't offer enough complex functionality to justify implementing a complex wrapper around it just to implement this simple extension. I'll just recommend the above 2-liner as a workaround. The "optimization system" as you refer to it (EFS) won't be on CPAN directly, but it is open source, and we hope to gain wider adoption in the coming months and years, so "evil hacks" are something I don't consider maintainable or desirable. If the patch isn't acceptable, then it just makes sense to not use File::ShareDir. I don't think it offers enough critical functionality to justify that level of complexity when there's a simple workaround. The downside will be that when we install someone's application, or perhaps a CPAN module which itself depends on File::ShareDir, then they won't work without code changes in our system. Not the end of the world, but this patch would have made such a migration transparent. It's your code, so it's your call. If you would rather wait for p5p to agree on extensions to the object API and use those, I can understand, but in the meantime, I felt that this patch added functionality without removing any. On Wed, Aug 18, 2010 at 1:08 AM, Reserved Local Account via RT < bug-File-ShareDir@rt.cpan.org> wrote: Show quoted text
> <URL: http://rt.cpan.org/Ticket/Display.html?id=60431 > > > From memory, the reason I didn't implement support for references in > @INC is that (from my reading of the coderef behaviour) the @INC > coderefs return filehandles to be read from. > > Many uses of File::ShareDir are not seeking to load a single file in > this way, but are instead locating a root directory within which many > dozens or hundreds of files may exist. > > Would this not mean that any such CODE reference @INC hooks could > never have returned a file or directory name, as the code may not > actually exist as files. > > The same seems to apply for objects in @INC, according to here anyway. > > http://perldoc.perl.org/functions/require.html > > The finding of a directory, or even a file name, does not seem to > exist in the concept as documented. I'm loath in modules this low > level to take actions without the blessings of #p5p. > > While you can't overload, one other option which is suitably evil > given what you want is to use Hook::LexWrap. > > Your "sub-class" would load File::ShareDir, and then hijack the normal > functions to replace them with your alternative behaviour. > > If the optimisation system in question will never go to CPAN, it is > quite acceptable. > > If it is going to CPAN, it is reasonable as long as it is the only > module that might over monkey-patch File::ShareDir in this way (which > may not be an entirely unreasonable assumption). > > Adam K > > On 18 August 2010 04:28, Phillip Moore via RT > <bug-File-ShareDir@rt.cpan.org> wrote:
> > Tue Aug 17 14:28:12 2010: Request 60431 was acted upon. > > Transaction: Ticket created by WPMOORE > > Queue: File-ShareDir > > Subject: Support for objects in @INC > > Broken in: 1.02 > > Severity: Normal > > Owner: Nobody > > Requestors: w.phillip.moore@gmail.com > > Status: new > > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=60431 > > > > > > > Adam et al -- > > > > This is not a bug report, but rather a request for a small new feature,
> and a patch that
> > implements it. > > > > The current version searches for the share dir relative to the
> directories in @INC, and simply
> > skips any references in @INC. This is perfectly reasonable behavior of
> course, and probably
> > the only obvious thing to do with @INC entries that aren't strings. > > > > However, we're using some interesting infrastructure that leverages the
> @INC objects
> > support, and the objects we create overload stringification to return the
> underlying directory
> > they represent. The code's purpose is to provide an INC method that
> checks for file existence
> > based on some cached data, thus avoiding filesystem I/O. > > > > The attached patch does two things. First of all, I refactored the @INC
> searching code into a
> > single subroutine, and second, it simply does a directory test of the
> quoted entry. This allows
> > the code to work with our objects (or anyone's object, if they just
> overload "" to return the
> > directory), and I believe it should still skip other references just
> fine.
> > > > Please let me know if this feature and patch acceptable to you. > > > > Thanks in advance, and all that.... > >
> >
Subject: Re: [rt.cpan.org #60431] Support for objects in @INC
Date: Wed, 18 Aug 2010 11:54:30 -0400
To: "w.phillip.moore [...] gmail.com via RT" <bug-File-ShareDir [...] rt.cpan.org>
From: Jesse Vincent <jesse [...] fsck.com>
Phillip, I (my company) actually make pretty heavy use of coderefs and objects in @INC. And there's never actually a directory on disk behind them in any of our implementations. All of the code that we're loading is generated or coming from non-disk sources. I'm somewhat curious about the performance problem you're trying to solve with your extra cache in @INC (since Perl does cache misses as well as hits), but that's a discussion for p5p, not File::ShareDir. -jesse
Subject: Re: [rt.cpan.org #60431] Support for objects in @INC
Date: Wed, 18 Aug 2010 12:57:56 -0400
To: bug-File-ShareDir [...] rt.cpan.org
From: Phillip Moore <w.phillip.moore [...] gmail.com>
My team in responsible for a product called EFS, which provides a generic mechanism for deploying releases of software in very large enterprises. The model we use is to deploy each distinct release of each software product independently. This means we have a separate directory structure for each and every CPAN release (these are each built for multiple perl compilers, and multiple platforms). This means that if you need to use something like Moose, which needs a total of about 40 different CPAN dependencies, you end up with 40 entries in @INC. Since these directory structures are ALL on a distributed filesystem, the cost of the negative directory lookups is very expensive, and startup times rise dramatically. The objects we put into @INC each represent a single directory, and we do all the filesystem IO up front, when the object is created, using some simple metadata files that are created by the tool that builds the modules. Each call to the INC method merely has to do a hash lookup to see if the requested file is available, rather than stat the filesystem. On Wed, Aug 18, 2010 at 11:55 AM, Jesse via RT < bug-File-ShareDir@rt.cpan.org> wrote: Show quoted text
> <URL: http://rt.cpan.org/Ticket/Display.html?id=60431 > > > > Phillip, > > I (my company) actually make pretty heavy use of coderefs and objects > in @INC. And there's never actually a directory on disk behind them in > any of our implementations. All of the code that we're loading is > generated or coming from non-disk sources. > > I'm somewhat curious about the performance problem you're trying to > solve with your extra cache in @INC (since Perl does cache misses as > well as hits), but that's a discussion for p5p, not File::ShareDir. > > -jesse > >
Subject: Re: [rt.cpan.org #60431] Support for objects in @INC
Date: Thu, 19 Aug 2010 03:08:07 +1000
To: bug-File-ShareDir [...] rt.cpan.org
From: Adam Kennedy <adamkennedybackup [...] gmail.com>
These two issues are the crux of the problem. File::ShareDir is very popular and has become the defacto standard for almost all modules that need to install and locate non-code read-only data files. It's done this primarily because it stays completely within the boundaries of the perl core and does not invent any new functionality. It may well be destined for the core as well at some future time. Because of this position, any new convention I invented may well become a defacto standard, and so the perl core might be faced with adopting the new mechanism (which looks nothing like the existing INC mechanism) or breaking back-compatibility. And so I would indeed rather wait for p5p to agree on extensions to the object API. With regards to the lexwrap approach, while you are welcome to use or not use File::ShareDir as you wish, you are correct that you would potentially not be compatible with a wide range of CPAN modules that use File::ShareDir. And it is precisely the need to provide File::ShareDir integration with your application across the whole CPAN that is the main reason for the lexwrap approach if you want this in the short term. It is a bit hacky, but I'd argue it's LESS so than the use of stringification overloading on object hooks in @INC. Adam K On 19 August 2010 01:40, w.phillip.moore@gmail.com via RT <bug-File-ShareDir@rt.cpan.org> wrote: Show quoted text
> The downside will be that when we install someone's application, or perhaps > a CPAN module which itself depends on File::ShareDir, then they won't work > without code changes in our system.  Not the end of the world, but this > patch would have made such a migration transparent. > > It's your code, so it's your call.   If you would rather wait for p5p to > agree on extensions to the object API and use those, I can understand, but > in the meantime, I felt that this patch added functionality without removing > any.
Subject: Re: [rt.cpan.org #60431] Support for objects in @INC
Date: Wed, 18 Aug 2010 13:23:45 -0400
To: bug-File-ShareDir [...] rt.cpan.org
From: Phillip Moore <w.phillip.moore [...] gmail.com>
OK, I give up.... I understand where you're coming from, but please bear in mind that *without* my patch, you have to override each and every method in File::ShareDir that parses @INC. IIRC, there's 4 of them. IOW, the code's not modular enough to make wrapping it with Lex::Wrap feasible. What I fail to understand is why we require some special extension to the @INC object API. it's already there -- overloading stringification. If noone uses it, File::ShareDir (with my patch, that is) will behave as it did before. This just allows the authors of those objects to add a simple, trivial method (when it makes sense to do so) that will allow File::ShareDir to work with those objects. I'm not claiming this is a grand strategic enhancement to said API. I'm just saying this builds a simple, tactical bridge between File::ShareDir and the use of such objects. Realistically, if we start to get lots of other modules that depend on File::ShareDir in our infrastructure, then I'll have to maintain a local patch to File::ShareDir (not the first time I've had to do this), and since as you claim this is becoming more widespread in use, that seems inevitable. But, like I said..... Your code, your call. Thanks for listening... On Wed, Aug 18, 2010 at 1:08 PM, Reserved Local Account via RT < bug-File-ShareDir@rt.cpan.org> wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=60431 > > > These two issues are the crux of the problem. > > File::ShareDir is very popular and has become the defacto standard for > almost all modules that need to install and locate non-code read-only > data files. It's done this primarily because it stays completely > within the boundaries of the perl core and does not invent any new > functionality. > > It may well be destined for the core as well at some future time. > > Because of this position, any new convention I invented may well > become a defacto standard, and so the perl core might be faced with > adopting the new mechanism (which looks nothing like the existing INC > mechanism) or breaking back-compatibility. > > And so I would indeed rather wait for p5p to agree on extensions to > the object API. > > With regards to the lexwrap approach, while you are welcome to use or > not use File::ShareDir as you wish, you are correct that you would > potentially not be compatible with a wide range of CPAN modules that > use File::ShareDir. > > And it is precisely the need to provide File::ShareDir integration > with your application across the whole CPAN that is the main reason > for the lexwrap approach if you want this in the short term. It is a > bit hacky, but I'd argue it's LESS so than the use of stringification > overloading on object hooks in @INC. > > Adam K > > On 19 August 2010 01:40, w.phillip.moore@gmail.com via RT > <bug-File-ShareDir@rt.cpan.org> wrote:
> > The downside will be that when we install someone's application, or
> perhaps
> > a CPAN module which itself depends on File::ShareDir, then they won't
> work
> > without code changes in our system. Not the end of the world, but this > > patch would have made such a migration transparent. > > > > It's your code, so it's your call. If you would rather wait for p5p to > > agree on extensions to the object API and use those, I can understand,
> but
> > in the meantime, I felt that this patch added functionality without
> removing
> > any.
> >
Subject: Re: [rt.cpan.org #60431] Support for objects in @INC
Date: Wed, 18 Aug 2010 13:27:16 -0400
To: "w.phillip.moore [...] gmail.com via RT" <bug-File-ShareDir [...] rt.cpan.org>
From: Jesse Vincent <jesse [...] fsck.com>
On Wed, Aug 18, 2010 at 01:23:55PM -0400, w.phillip.moore@gmail.com via RT wrote: Show quoted text
> I understand where you're coming from, but please bear in mind that > *without* my patch, you have to override each and every method in > File::ShareDir that parses @INC. IIRC, there's 4 of them. IOW, the code's > not modular enough to make wrapping it with Lex::Wrap feasible.
_That_ sounds like a good patch to contribute that would both improve the code and make the lexwrapping a much simpler proposition.
Subject: Re: [rt.cpan.org #60431] Support for objects in @INC
Date: Wed, 18 Aug 2010 13:46:33 -0400
To: bug-File-ShareDir [...] rt.cpan.org
From: Phillip Moore <w.phillip.moore [...] gmail.com>
It was a one-line change from the previous patch I sent. Attached here, if you want it.... On Wed, Aug 18, 2010 at 1:28 PM, Jesse via RT <bug-File-ShareDir@rt.cpan.org Show quoted text
> wrote:
Show quoted text
> <URL: http://rt.cpan.org/Ticket/Display.html?id=60431 > > > > > > On Wed, Aug 18, 2010 at 01:23:55PM -0400, w.phillip.moore@gmail.com via RT > wrote:
> > I understand where you're coming from, but please bear in mind that > > *without* my patch, you have to override each and every method in > > File::ShareDir that parses @INC. IIRC, there's 4 of them. IOW, the
> code's
> > not modular enough to make wrapping it with Lex::Wrap feasible.
> > _That_ sounds like a good patch to contribute that would both improve > the code and make the lexwrapping a much simpler proposition. > >

Message body is not shown because sender requested not to inline it.

Subject: Re: [rt.cpan.org #60431] Support for objects in @INC
Date: Thu, 19 Aug 2010 10:47:58 +1000
To: bug-File-ShareDir [...] rt.cpan.org
From: Adam Kennedy <adamkennedybackup [...] gmail.com>
Indeed. I'd be quite happy to refactor File::ShareDir to make it much simpler to hook around. Adam K On 19 August 2010 03:28, Jesse via RT <bug-File-ShareDir@rt.cpan.org> wrote: Show quoted text
>       Queue: File-ShareDir >  Ticket <URL: http://rt.cpan.org/Ticket/Display.html?id=60431 > > > > > > On Wed, Aug 18, 2010 at 01:23:55PM -0400, w.phillip.moore@gmail.com via RT wrote:
>> I understand where you're coming from, but please bear in mind that >> *without* my patch, you have to override each and every method in >> File::ShareDir that parses @INC.   IIRC, there's 4 of them.  IOW, the code's >> not modular enough to make wrapping it with Lex::Wrap feasible.
> > _That_ sounds like a good patch to contribute that would both improve > the code and make the lexwrapping a much simpler proposition. > >
RT-Send-CC: jesse [...] fsck.com, w.phillip.moore [...] gmail.com, adamkennedybackup [...] gmail.com
Hi, It has been four years since you guys' discussion on this request of supporting objects in @INC. I wonder if there is still plan to do it... My company is also heavily using in @INC objects with overloading of stringification. I also really hope we make a change in File::ShareDir to support that. Thanks, Zhenyi
The common sense of the patch has been committed as eb120ce ShareDir.pm: extract common sub _search_inc_path If another patch would come around extracting the approval of the loop element into a dedicated check routine, I would be fine, too.
Looks to me as if the resolution provided in 1.106 is widely accepted.