Skip Menu |

This queue is for tickets about the MIME-Types CPAN distribution.

Report information
The Basics
Id: 104945
Status: resolved
Priority: 0/
Queue: MIME-Types

People
Owner: Nobody in particular
Requestors: perl [...] pied.nu
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: Can't find types.db when inside a PAR
PAR::Packer adds #line 1 "MIME/Types.pm" to Types.pm when packing. This means that MIME::Types can't find types.db The line : || File::Spec->catfile(dirname(__FILE__), 'types.db'); Should be replaced with || File::Spec->catfile(dirname( $INC{'MIME/Types.pm'} ), 'types.db'); Or better yet, a global $MIME::Types::DB should be available so the default types.db can be set.
Subject: Re: [rt.cpan.org #104945] Can't find types.db when inside a PAR
Date: Wed, 3 Jun 2015 23:19:20 +0200
To: Philip Gwyn via RT <bug-MIME-Types [...] rt.cpan.org>
From: Mark Overmeer <mark [...] overmeer.net>
* Philip Gwyn via RT (bug-MIME-Types@rt.cpan.org) [150603 20:16]: Show quoted text
> Wed Jun 03 16:15:45 2015: Request 104945 was acted upon. > Transaction: Ticket created by GWYN > Queue: MIME-Types > Subject: Can't find types.db when inside a PAR > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=104945 > > > PAR::Packer adds > #line 1 "MIME/Types.pm" > > to Types.pm when packing. This means that MIME::Types can't find types.db
You answer this bug-report yourself: MIME::Types is not doing anything wrong. The content of __FILE__ is clearly defined by Perl, so I can use it. If PAR::Packer feels the need to mutulate my package, then it (its users) suffer the consequences, not me. It would be possible to fix PAR::Packer to add the correct path name. Or to remove that line I found some (older) nodes on PerlMonks about the subject. For instance http://www.perlmonks.org/?node_id=925167 -- Regards, MarkOv ------------------------------------------------------------------------ Mark Overmeer MSc MARKOV Solutions Mark@Overmeer.net solutions@overmeer.net http://Mark.Overmeer.net http://solutions.overmeer.net
Perl 5.10.1 doco : Special Literals The special literals __FILE__, __LINE__, and __PACKAGE__ represent the current filename, line number, and package name at that point in your program. They may be used only as separate tokens; they will not be interpolated into strings. I see no hard guarantee in that description. And, in general, a library that allows its user to specify where it will find its data files.
Subject: Re: [rt.cpan.org #104945] Can't find types.db when inside a PAR
Date: Thu, 11 Jun 2015 20:11:33 +0200
To: Philip Gwyn via RT <bug-MIME-Types [...] rt.cpan.org>
From: Mark Overmeer <mark [...] overmeer.net>
* Philip Gwyn via RT (bug-MIME-Types@rt.cpan.org) [150611 18:04]: Show quoted text
> Queue: MIME-Types > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=104945 > > > Perl 5.10.1 doco : > > Special Literals > The special literals __FILE__, [...] represent the current > filename, [...] > > I see no hard guarantee in that description.
There is a very hard definition what a filename means in the OS context. A filename points to a sequence of bytes on disk. So, "current filename" means "the location of this sequences of bytes on disk" Show quoted text
> And, in general, a library that allows its user to specify where > it will find its data files.
I do not understand this sentence. -- MarkOv ------------------------------------------------------------------------ Mark Overmeer MSc MARKOV Solutions Mark@Overmeer.net solutions@overmeer.net http://Mark.Overmeer.net http://solutions.overmeer.net
On Thu Jun 11 14:03:08 2015, GWYN wrote: Show quoted text
> And, in general, a library that allows its user to specify where it > will find its data files.
Gah! You have db_file... so this comment is irrelevant.
On Thu Jun 11 14:11:54 2015, Mark@Overmeer.net wrote: Show quoted text
> There is a very hard definition what a filename means in the OS context. > A filename points to a sequence of bytes on disk. So, "current filename" > means "the location of this sequences of bytes on disk"
What happens if @INC contains a code ref that loads the code from (eg) a database? From perlvar: You can also insert hooks into the file inclusion system by putting Perl code directly into @INC. Those hooks may be subroutine refer- ences, array references or blessed objects. See "require" in perlfunc for details. From perlfunc: Subroutine references are the simplest case. When the inclusion system walks through @INC and encounters a subroutine, this subroutine gets called with two parameters, the first being a reference to itself, and the second the name of the file to be included (e.g. "Foo/Bar.pm"). The subroutine should return "undef" or a filehandle, from which the file to include will be read. If "undef" is returned, "require" will look at the remaining elements of @INC.
To satisfy my curiosity, I cooked up the attached test. It outputs the following: including Something This is /loader/0x57247a0/Something line 4 This is a warning at /loader/0x57247a0/Something line 5.
Subject: inc
Download inc
application/octet-stream 368b

Message body not shown because it is not plain text.

On 2015-06-03 17:19:38, Mark@Overmeer.net wrote: Show quoted text
> * Philip Gwyn via RT (bug-MIME-Types@rt.cpan.org) [150603 20:16]:
> > Wed Jun 03 16:15:45 2015: Request 104945 was acted upon. > > Transaction: Ticket created by GWYN > > Queue: MIME-Types > > Subject: Can't find types.db when inside a PAR > > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=104945 > > > > > PAR::Packer adds > > #line 1 "MIME/Types.pm" > > > > to Types.pm when packing. This means that MIME::Types can't find > > types.db
> > You answer this bug-report yourself: MIME::Types is not doing anything > wrong. The content of __FILE__ is clearly defined by Perl, so I can > use it. If PAR::Packer feels the need to mutulate my package, then it > (its users) suffer the consequences, not me.
If I may interfere --- I don't think the question is whether MIME::Types is doing something wrong or not. The question is whether PAR is popular or important enough so it deserves some help from CPAN modules to do the job right. And I think the answer is yes. Regards, Slaven
Currently, inside a PAR, you have to use MIME::Types->new(db_file=>$file). This is a problem if you use modules (say MIME::Lite) that don't use the OO interface. Even if they did, they'd all have to be fixed. The solution is to build a MIME::Types object at start up. This works because MIME::Types caches the parsed types.db in memory. This is obviously sub-optimal.
Subject: Re: [rt.cpan.org #104945] Can't find types.db when inside a PAR
Date: Thu, 11 Jun 2015 23:29:50 +0200
To: Philip Gwyn via RT <bug-MIME-Types [...] rt.cpan.org>
From: Mark Overmeer <mark [...] overmeer.net>
* Philip Gwyn via RT (bug-MIME-Types@rt.cpan.org) [150611 19:55]: Show quoted text
> Queue: MIME-Types > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=104945 > > > Currently, inside a PAR, you have to use > MIME::Types->new(db_file=>$file). This is a problem if you use modules > (say MIME::Lite) that don't use the OO interface. Even if they did, > they'd all have to be fixed. > > The solution is to build a MIME::Types object at start up. This works > because MIME::Types caches the parsed types.db in memory. This is > obviously sub-optimal.
Actually, in the current implementation, it is quite efficient in memory. If you program uses forks, it is certainly also smart to start initializing the object early. There are more modules which expect external files. For instance, my XML::Compile modules need xsd and wsdl files to initialize itself. I do not know how PAR mimics the structure of installed modules. Does it expect to see only pm files? If you have a solutions, of course I can add a section in the man-page how to correctly use it with PAR, just like there is a section about mod_perl. -- Regards, MarkOv ------------------------------------------------------------------------ Mark Overmeer MSc MARKOV Solutions Mark@Overmeer.net solutions@overmeer.net http://Mark.Overmeer.net http://solutions.overmeer.net
Subject: Re: [rt.cpan.org #104945] Can't find types.db when inside a PAR
Date: Fri, 12 Jun 2015 00:01:20 +0200
To: Slaven_Rezic via RT <bug-MIME-Types [...] rt.cpan.org>
From: Mark Overmeer <mark [...] overmeer.net>
* Slaven_Rezic via RT (bug-MIME-Types@rt.cpan.org) [150611 19:25]: Show quoted text
> Queue: MIME-Types > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=104945 > > > I don't think the question is whether MIME::Types is doing something > wrong or not. The question is whether PAR is popular or important enough > so it deserves some help from CPAN modules to do the job right. And I > think the answer is yes.
The statement "MIME::Types is wrongly using __FILE__, because PAR breaks", as the report says, is incorrect. PAR is playing tricks, and those tricks cause __FILE__ to have a different content than the perl docs say. I don't think the %INC trick is correct either. Of course, if there is a solution which does not punish other users of the module --and which is maintainable-- then I would add that. For instance, if you can tell me where PAR stores the table file, I could add something like my $file = $ENV{PAR_RUN} ? .... : (dirname __FILE__).'types.db'; It may also be possible to change PAR to fill __FILE__ correctly. The problem is caused by the #line 1 "MIME/Types.pm" Probably only used for error messages? Another solution I can think of: the first loader of the module can specify the database file. But you do not always have access to that source to adapt it to the needs of PAR. So, it could also be solved via an environment variable. my $file = $ENV{PERL_MIME_TYPES_DB} || (dirname __FILE__).'types.db'; I think the last option is the best. -- Regards, MarkOv ------------------------------------------------------------------------ Mark Overmeer MSc MARKOV Solutions Mark@Overmeer.net solutions@overmeer.net http://Mark.Overmeer.net http://solutions.overmeer.net
Le Jeu 11 Juin 2015 17:30:08, Mark@Overmeer.net a écrit : Show quoted text
> Actually, in the current implementation, it is quite efficient in > memory. If you program uses forks, it is certainly also smart to > start initializing the object early.
The inefficiency is having to load and parse a text file every time the program is run, just in case the program might use MIME::Types' functionnal API. The in-memory representation is compact. And given that it is subsequently a (mostly) read-only structure, any sane OS will share the memory between parent and forked children.
Le Jeu 11 Juin 2015 18:01:39, Mark@Overmeer.net a écrit : Show quoted text
> my $file = $ENV{PERL_MIME_TYPES_DB} || (dirname __FILE__).'types.db'; > > > I think the last option is the best.
The attached patch implements $MIME::Types::DB_FILE, including a small test case and documentation patch.
I clicked Submit to early. Here is the actual patch. What's more, I think this patch has a surprise : If types.db is cached in-memory, then $DB_FILE is change, the new $DB_FILE won't be loaded.
Subject: Philip_Gwyn-MIME_Types-DB_FILE.01.patch
diff -rubN MIME-Types-2.09-orig/lib/MIME/Types.pm MIME-Types-2.09-PG/lib/MIME/Types.pm --- MIME-Types-2.09-orig/lib/MIME/Types.pm 2014-09-14 12:12:24.000000000 -0400 +++ MIME-Types-2.09-PG/lib/MIME/Types.pm 2015-06-11 14:18:33.000000000 -0400 @@ -19,6 +19,8 @@ my %typedb; sub new(@) { (bless {}, shift)->init( {@_} ) } +our $DB_FILE; + sub init($) { my ($self, $args) = @_; keys %typedb or $self->_read_db($args); @@ -32,6 +34,7 @@ my $only_iana = $args->{only_iana}; my $db = $args->{db_file} + || $DB_FILE || File::Spec->catfile(dirname(__FILE__), 'types.db'); local *DB; diff -rubN MIME-Types-2.09-orig/lib/MIME/Types.pod MIME-Types-2.09-PG/lib/MIME/Types.pod --- MIME-Types-2.09-orig/lib/MIME/Types.pod 2014-09-14 12:12:24.000000000 -0400 +++ MIME-Types-2.09-PG/lib/MIME/Types.pod 2015-06-11 14:40:50.000000000 -0400 @@ -244,6 +244,23 @@ =back +=head1 VARIABLES + +=over 4 + +=item B<$MIME::Types::DB_FILE> + +Location of C<types.db>, the database of known extensions. Normally, +MIME::Types looks in the directory were C<Types.pm> is installed. You may +use this variable to specify another location for C<types.db>. + +example: + + $MIME::Types::DB_FILE = File::Spec->catfile( $datadir, "types.db" ); + +=back + + =head1 SEE ALSO This module is part of MIME-Types distribution version 2.09, diff -rubN MIME-Types-2.09-orig/t/20types.t MIME-Types-2.09-PG/t/20types.t --- MIME-Types-2.09-orig/t/20types.t 2014-09-14 12:12:24.000000000 -0400 +++ MIME-Types-2.09-PG/t/20types.t 2015-06-11 14:34:26.000000000 -0400 @@ -98,3 +98,5 @@ ok($r7, 'type sheet'); ok($r7->isBinary); ok(!$r7->isText); + + diff -rubN MIME-Types-2.09-orig/t/23db_file.t MIME-Types-2.09-PG/t/23db_file.t --- MIME-Types-2.09-orig/t/23db_file.t 1969-12-31 19:00:00.000000000 -0500 +++ MIME-Types-2.09-PG/t/23db_file.t 2015-06-11 14:26:46.000000000 -0400 @@ -0,0 +1,22 @@ +#!/usr/bin/env perl +# +# Test reporting warnings, errors and family. +# + +use strict; +use warnings; + +use lib qw(lib t); + +use Test::More tests => 3; + +use FindBin; +use File::Spec; +use MIME::Types; + +local $MIME::Types::DB_FILE = File::Spec->catfile( $FindBin::Bin, 'fake-types.db' ); +my $a = MIME::Types->new; +isa_ok( $a, 'MIME::Types' ); + +is($a->mimeTypeOf('my.honk')->type, 'application/x-honk'); +is($a->mimeTypeOf('my.pdf')->type, 'application/x-not-pdf'); diff -rubN MIME-Types-2.09-orig/t/fake-types.db MIME-Types-2.09-PG/t/fake-types.db --- MIME-Types-2.09-orig/t/fake-types.db 1969-12-31 19:00:00.000000000 -0500 +++ MIME-Types-2.09-PG/t/fake-types.db 2015-06-11 14:32:51.000000000 -0400 @@ -0,0 +1,8 @@ +2:EXTENSIONS +honk;application/x-honk +pdf;application/x-not-pdf + +2:application:: +x-honk;honk; +x-not-pdf;pdf; +
Subject: Re: [rt.cpan.org #104945] Can't find types.db when inside a PAR
Date: Fri, 12 Jun 2015 10:46:43 +0200
To: Philip Gwyn via RT <bug-MIME-Types [...] rt.cpan.org>
From: Mark Overmeer <solutions [...] overmeer.net>
* Philip Gwyn via RT (bug-MIME-Types@rt.cpan.org) [150611 18:55]: Show quoted text
> Queue: MIME-Types > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=104945 > > > On Thu Jun 11 14:11:54 2015, Mark@Overmeer.net wrote:
> > There is a very hard definition what a filename means in the OS context. > > A filename points to a sequence of bytes on disk. So, "current filename" > > means "the location of this sequences of bytes on disk"
> > What happens if @INC contains a code ref that loads the code from (eg) a > database?
I do not see any relation between your description of @INC (which I alreay knew) and my quoted remark about the strict meaning of the word "filename". -- MarkOv ------------------------------------------------------------------------ drs Mark A.C.J. Overmeer MARKOV Solutions Mark@Overmeer.net solutions@overmeer.net http://Mark.Overmeer.net http://solutions.overmeer.net
Subject: Re: [rt.cpan.org #104945] Can't find types.db when inside a PAR
Date: Fri, 12 Jun 2015 10:57:10 +0200
To: Philip Gwyn via RT <bug-MIME-Types [...] rt.cpan.org>
From: Mark Overmeer <solutions [...] overmeer.net>
* Philip Gwyn via RT (bug-MIME-Types@rt.cpan.org) [150611 23:37]: Show quoted text
> Queue: MIME-Types > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=104945 > > > Le Jeu 11 Juin 2015 17:30:08, Mark@Overmeer.net a écrit :
> > Actually, in the current implementation, it is quite efficient in > > memory. If you program uses forks, it is certainly also smart to > > start initializing the object early.
> > The inefficiency is having to load and parse a text file every time > the program is run, just in case the program might use MIME::Types' > functionnal API.
It is more inefficient to do it once, than in every thread of a daemon. The core problem is that look-ups require an index, so you have to build that first, before you can use the data. Of course, this can be solved by using a real database... which gives so many extra complications. The functional API is a wrapper around the OO implementation. Is see no way why a functional interface could avoid reading the whole file. Show quoted text
> The in-memory representation is compact. And given that it is > subsequently a (mostly) read-only structure, any sane OS will share the > memory between parent and forked children.
Well... reference counting in Perl seriously hinders page sharing. -- MarkOv ------------------------------------------------------------------------ drs Mark A.C.J. Overmeer MARKOV Solutions Mark@Overmeer.net solutions@overmeer.net http://Mark.Overmeer.net http://solutions.overmeer.net
Subject: Re: [rt.cpan.org #104945] Can't find types.db when inside a PAR
Date: Fri, 12 Jun 2015 11:08:21 +0200
To: Philip Gwyn via RT <bug-MIME-Types [...] rt.cpan.org>
From: Mark Overmeer <solutions [...] overmeer.net>
* Philip Gwyn via RT (bug-MIME-Types@rt.cpan.org) [150611 23:39]: Show quoted text
> Queue: MIME-Types > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=104945 > > > Le Jeu 11 Juin 2015 18:01:39, Mark@Overmeer.net a écrit :
> > my $file = $ENV{PERL_MIME_TYPES_DB} || (dirname __FILE__).'types.db'; > > > > > > I think the last option is the best.
> > The attached patch implements $MIME::Types::DB_FILE, including a small > test case and documentation patch.
Having a global variable is not a sufficient solution. At least two situations are not covered: 1) when your script starts with local $MIME::Types::DB = '/tmp/types.db'; use Some::Types::Module; and that other module initializes the table inside a BEGIN, it will already have attempted to read the file from the original location before it is set. 2) it will not help enough in the PAR case. All scripts in the PAR archive must be aware that one of their modules may use MIME::Types, and set the variable accordingly. It is far much safer when the PAR environment hides that for all. I am unsure whether it is useful to add both options, because of the first problem. I think that only an environment variable can be useful. -- Regards, MarkOv ------------------------------------------------------------------------ drs Mark A.C.J. Overmeer MARKOV Solutions Mark@Overmeer.net solutions@overmeer.net http://Mark.Overmeer.net http://solutions.overmeer.net
Le Ven 12 Juin 2015 04:47:06, solutions@overmeer.net a écrit : Show quoted text
> I do not see any relation between your description of @INC (which I > alreay knew) and my quoted remark about the strict meaning of the > word "filename".
It was more of a rhetorical question, which I answered with my short test. The point I am trying to make is that while the docs say "__FILE__ is a filename", and (as you point out) "filename are indexes to bytes on a disk." It is trivial form __FILE__ to contain a string that doesn't usefully index any bytes on a disk.
Le Ven 12 Juin 2015 05:08:34, solutions@overmeer.net a écrit : Show quoted text
> I am unsure whether it is useful to add both options, because of the > first problem. I think that only an environment variable can be useful.
If this is the sole option you are prepared to implement, I will not complain.
Subject: Re: [rt.cpan.org #104945] Can't find types.db when inside a PAR
Date: Fri, 12 Jun 2015 17:59:59 +0200
To: Philip Gwyn via RT <bug-MIME-Types [...] rt.cpan.org>
From: Mark Overmeer <mark [...] overmeer.net>
* Philip Gwyn via RT (bug-MIME-Types@rt.cpan.org) [150612 15:43]: Show quoted text
> Queue: MIME-Types > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=104945 > > > The point I am trying to make is that while the docs say "__FILE__ > is a filename", and (as you point out) "filename are indexes to bytes on > a disk." It is trivial form __FILE__ to contain a string that doesn't > usefully index any bytes on a disk.
But that case is clearly not according to the specification of __FILE__ to use it differently than to contain a filename with perl source, hence a bug (either a bug in the code, or a bug in the specification) if it is not. So, in my opinion, PAR is in conflict with the perl5 "specification", which is its manual pages. With the environment variable we introduce, we let get PAR away with its bug. Which is not that much of a problem for me. Can you tell me where PAR puts my type.db file, so that I can include that in the docs? -- MarkOv ------------------------------------------------------------------------ drs Mark A.C.J. Overmeer MARKOV Solutions Mark@Overmeer.net solutions@overmeer.net http://Mark.Overmeer.net http://solutions.overmeer.net
Le Ven 12 Juin 2015 12:00:20, Mark@Overmeer.net a écrit : Show quoted text
> But that case is clearly not according to the specification of __FILE__ > to use it differently than to contain a filename with perl source, > hence a bug (either a bug in the code, or a bug in the specification) > if it is not.
I was referring to this test, that does not use PAR https://rt.cpan.org/Ticket/Display.html?id=104945#txn-1506791 Show quoted text
> Can you tell me where PAR puts my type.db file, so that I can include > that in the docs?
PAR does not (that I know of) do anything special with types.db. If one is packing MIME::Types, one has to explicitly include it with -a lib/MIME/types.db. Other modules (like PDF::API2) must also have their data files explicitly included (eg unipaper.txt). PAR creates a zip file. This file has a directory structure similar to how perl install modules. So types.db would be lib/MIME/types.db within the zip file. At execution, PAR unpacks the zip into a cache directory. The rules for generating this directory name are convoluted. The full path to the cache directory is in $ENV{PAR_TEMP} so code inside the PAR may access files in the cache directory. Examples of where types.db might end up: /tmp/par-USER/cache-HASH/inc/lib/MIME/types.db /tmp/USER/private/PAR/user-USER/cache-HASH/inc/lib/MIME/types.db Where USER is the current user name and HASH is a crypto-hash of the entire PAR file, or a string specified when the PAR is created. PAR files can also be self-extracting executable. What this means for MIME::Types is that you would use the following to find types.db when running from a PAR. $db_file = File::Spec->catfile( $ENV{PAR_TEMP}, qw( inc lib MIME types.db ) );
On 2015-06-12 12:50:18, GWYN wrote: Show quoted text
> Le Ven 12 Juin 2015 12:00:20, Mark@Overmeer.net a écrit :
> > But that case is clearly not according to the specification of > > __FILE__ > > to use it differently than to contain a filename with perl source, > > hence a bug (either a bug in the code, or a bug in the specification) > > if it is not.
> > I was referring to this test, that does not use PAR > https://rt.cpan.org/Ticket/Display.html?id=104945#txn-1506791 >
> > Can you tell me where PAR puts my type.db file, so that I can include > > that in the docs?
> > PAR does not (that I know of) do anything special with types.db. If > one is packing MIME::Types, one has to explicitly include it with -a > lib/MIME/types.db. Other modules (like PDF::API2) must also have > their data files explicitly included (eg unipaper.txt).
This is not what I observe. types.db is automatically included. The sample script #!perl use MIME::Types; for (@INC) { my $candidate = "$_/MIME/types.db"; warn $candidate if -r $candidate; } __END__ outputs the following after being packed with "pp" and no extra arguments: /tmp/par-657365727465/cache-3737f86569047eebe851dce4bdcd739615edb166/inc/lib/MIME/types.db at script/test.pl line 5. The exception list seems to be in Module::ScanDeps, which has this line: 'MIME/Types.pm' => [qw( MIME/types.db )], BTW, for Tk scripts the inclusion of icon images works with PAR because Tk modules usually walk @INC in the search for the icon images (using the Tk->findINC("imagename.suffix") call).
Le Ven 12 Juin 2015 16:03:17, SREZIC a écrit : Show quoted text
> This is not what I observe. types.db is automatically included.
My Makefile was written years ago, back before Module::ScanDeps had a special case for types.db Show quoted text
> BTW, for Tk scripts the inclusion of icon images works with PAR > because Tk modules usually walk @INC in the search for the icon images > (using the Tk->findINC("imagename.suffix") call).
That seems wasteful. What's more, Tk->findINC will not respect coderefs in @INC.
On 2015-06-12 16:20:22, GWYN wrote: Show quoted text
> Le Ven 12 Juin 2015 16:03:17, SREZIC a écrit : >
[...] Show quoted text
>
> > BTW, for Tk scripts the inclusion of icon images works with PAR > > because Tk modules usually walk @INC in the search for the icon > > images > > (using the Tk->findINC("imagename.suffix") call).
> > That seems wasteful. What's more, Tk->findINC will not respect > coderefs in @INC.
This was meant just as another example module where something INC-like was used for locating extra non-pm files (OK, this is @INC and not %INC). And why should this be wasteful? In a typical custom perl installation the arch sitelib is the first one in @INC, and even if it was the last directory in @INC --- a few stat() calls a hardly performance-relevant these days. But this probably belongs to the Tk RT queue...
Le Ven 12 Juin 2015 16:32:49, SREZIC a écrit : Show quoted text
> This was meant just as another example module where something INC-like > was used for locating extra non-pm files (OK, this is @INC and not > %INC). > > And why should this be wasteful? In a typical custom perl installation > the arch sitelib is the first one in @INC, and even if it was the last > directory in @INC --- a few stat() calls a hardly performance-relevant > these days. But this probably belongs to the Tk RT queue...
Everybody has their own idea about where to install data files and how to find them. Everybody implements these ideas seperately. IMHO, everybody should be using File::ShareDir and File::ShareDir::Install. Doing so would mean Module::ScanDeps could Just Work, rather then maintaining a list of special cases. But yes, we are getting very far away from the initial discussion. I agree that $ENV{PERL_MIME_TYPES_DB} is an adequate solution for this problem.
Subject: Re: [rt.cpan.org #104945] Can't find types.db when inside a PAR
Date: Mon, 15 Jun 2015 17:33:58 +0200
To: Philip Gwyn via RT <bug-MIME-Types [...] rt.cpan.org>
From: Mark Overmeer <solutions [...] overmeer.net>
* Philip Gwyn via RT (bug-MIME-Types@rt.cpan.org) [150612 15:45]: Show quoted text
> Queue: MIME-Types > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=104945 > > > Le Ven 12 Juin 2015 05:08:34, solutions@overmeer.net a écrit :
> > I am unsure whether it is useful to add both options, because of the > > first problem. I think that only an environment variable can be useful.
> > If this is the sole option you are prepared to implement, I will not complain.
Released as MIME::Types version 2.10 Thanks for your contribution. -- MarkOv ------------------------------------------------------------------------ Mark Overmeer MSc MARKOV Solutions Mark@Overmeer.net solutions@overmeer.net http://Mark.Overmeer.net http://solutions.overmeer.net
Le Lun 15 Juin 2015 11:34:17, solutions@overmeer.net a écrit : Show quoted text
> Released as MIME::Types version 2.10 > Thanks for your contribution.
Cheers.