Closed moollaza closed 9 years ago
@moollaza I believe this is much trickier than you suspect. The -I
is going to the perl interpreter. So far as I know (thought I am going to check) there is no way to access this info from inside the interpreter. You can see the effect by, say, checking that all the directories in @INC
exist, but you won't know if it's because of a specific user-supplied switch or a compiled in option.
The user-supplied ones will always be at the front of @INC
, but how many are there? Is the first compiled-in on even guaranteed to exist? (No, not really.)
Like I said, I'll look into it, mostly because it's an interesting problem, but I wouldn't expect a solution too soon. :grin:
@mwmiller I don't believe the -I
is going to the Perl interpreter directly? We're grabbing it in bin/duckpan
(here via GetOpt::Long
) and passing the list of paths to use lib
.
I was thinking before that point we could perhaps use Path::Tiny
to verify if that path exists? Or do something along those lines...
On a related note, I was wondering if we can/should move that logic out of bin/duckpan
into Duckpan.pm
? I'm not sure if there are any benefits, it just feels a little weird to me that it's not in Duckpan.pm
:)
We're grabbing it in bin/duckpan
I was looking in Duckpan.pm, of course. Part of why I found it interesting was trying to figure out how it went to the interpreter! I guess I should try to know more about the project structure. :grin:
I think you need to keep the code there, for the most part, to get the switches to show up in the right place.
Fixed in #157
When testing duckpan I often include the local duckpan lib to make sure the modified local files are used. If however, you make a typo and the path doesn't exist, no warnings are given
e.g.
duckpan -I../duckwrong/lib server
would carry on as usual but the specified lib will not be loaded as it doesn't exist.