Integrate mylib? about perl5i HOT 8 OPEN

I would classify that as unexpected, unpleasant behaviour.

from perl5i.

Your reasoning?

from perl5i.

It prepends directories I didn't specify to @inc, messing with @inc behind my back is not nice. Everything else in perl5i (except strict, which is a special case) has enhanced existing things. You could ignore the enhancements if you wanted to. But with mylib I would have to worry that the directory my script is in (or its parent directory) might have a lib directory and the lib directory might have a .pm or .pmc file that matches a module I am using. Imagine helper scripts in a source directory that use the installed version of the module, suddenly they will use the new (possibly buggy) version of the module instead of the installed version (which presumably has been tested). Also, I have to take extra pains to not have it prepend stuff (e.g. shifting @inc in a BEGIN block after use perl5i).

from perl5i.

Thanks for expanding on that.

Part of perl5i is to make Perl DTRT for 99% of the cases and only for the remaining 1% do you have to turn it off. To that end, for every scenario where you have a module in lib/ and you don't want to use it I'm pretty sure there's about 100 where you do. Since the @inc path is absolute it's not nearly as dangerous as, say, having the cwd in @inc which we already do and the sky remains fixed firmly overhead.

You're right that having to muck with @inc in a BEGIN block to turn it off is ugly. I think a "no mylib" would allow those 1% to easily turn off the behavior.

There is one scenario where its a bad idea, and that's in module testing since that wants to use blib, not lib. That's a pretty broad case. It might make sense to prepend blib/lib as well, but then I'm wondering if that's a bit too much of a good thing.

from perl5i.

But is using ./lib the right thing? Is this something we want to encourage people to do? Or would we rather people use Module::Starter to make installable modules and have them install the modules into the right place (rather than some random place). If we are talking about delivering projects that are supposed to be self-contained, well, that is what PAR is for.

from perl5i.

Including mylib doesn't eliminate any of that. And they're all relatively complicated things that have to be discovered and configured and learned by both the developer and the user. Shipping a program as a module is often overkill, your users have to understand the Perl module installation process just to get their program running. PAR is neat, but it creates opaque files which are difficult to debug.

As I use more and more PHP there's definite value in being able to just unpack a source archive and have it work. So to the question of whether this is the sort of thing we want to encourage people to do I say yes.

from perl5i.

I do the 'use FindBin; use lib "$FindBin::Bin/../lib";' thing at work precisely so that I don't have to worry about any environmental setup. The only thing necessary is a known path to the correct perl executable.

I do use the whole perl toolchain to put together the final tarball for installation, but at runtime, nothing needs to be set up; everything is done relative to the program location.

from perl5i.

The only worry I have with lib being an implicit include is from the attack standpoint. In the event of setuid scripts, all an attacker has to get access to is write to the directory containing the script, add a 'lib' dir ( which could easily be overlooked ) and place broken copies of things in it to abuse unsuspecting ( or root ) users.

This is already a problem of sorts with '.' being included by default, but including that is less devious as you have a more visible target. I might be just blowing this problem out of proportion, but I think its a vector better thought about than not.

including "$FindBin::Bin/lib" by default is less bad, but including cwd . '/lib' is an epic bad idea.

from perl5i.