Bug #18219 for Module-Install: Interactions between inc/Module/Install and installed Module::Install

via RT wrote: Show quoted text
This is a known problem (in my head at least) but thanks for reporting it properly. I wasn't sure whether or not it was starting to cause a problem in the wild yet. The reason it exists at all is part of the principle of biasing in favour of the users on failures, because authors are far more likely to complain in detail via proper channels and know how to both get around problems, or to fix them. As for how to fix this, the plan I'd had in mind was to get Module::Install aware internally of whether or not it's running in author mode or user module, and make the load_extenstions stuff only check in the right group of directories for extensions. As a starting point, I've also added synchronised versions to all files now, so that at least we have some ability to write code that knows that the extensions match the core. But after the error my first attempt at writing such code introduced in 0.58 and 0.59 I'm obviously a little caitious about turning on such functionality without understanding a bit more how the internals of MI work. Adam K

adam@phase-n.com via RT wrote: Show quoted text
I wish you luck on this since I cannot think of a way to determine whether you are running as author or user, unless you require the author to add an explicit commandline option. Thinking aloud, if prior to running 'make dist' the contents of the './inc' directory were absent, then author mode could be assumed. But that would also mean that 'make distclean' would have to delete './inc' (and the author shouldn't add that directory to their VCS). Alternatively, the only time that the custom './inc' folder was created was in response to 'make dist' and 'make disttest' then you would still be good to go. In this case, the presence of files in './inc' would be the switch between author and user mode, and you'd have a BEGIN { use lib './inc'; } line in the sitribution files, right? Or have you already considered this? John -- John Peacock Director of Information Research and Technology Rowman & Littlefield Publishing Group 4720 Boston Way Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5747

Show quoted text
I just have the situation that somebody installed inc::Module::Install for me. I haven't asked for it. It would take me quite a lot of work to find out who did this. I will not do it, because it will help nobody and will happen again anyway. But I'd say it is extreme action at a distance to simply rely that 'use inc::Module::Install will always load the one in ./inc/Module/Install.pm. It is simply wrong thinking. Programs must not rely on the inexistence of certain files. I suggest two things: first add a comment to every file in inc declaring the name of the distribution it was made for. This helps us to track unsolicited installations. Second amend the docs that every author of Module::Install must write a 'use lib "."' before the 'use inc::Module::Install' line. WDYT?

I believe I understand it now and I see how wrong I was. It took me such an awful lot of time to track the reasons why the module POD::Credentials is broken (#41743) that I wonder what might prevent such things to happen. Maybe some more visibility of the magicians genius? An empty directory with a dot name is not what I'd call self explaining. Maybe a small text file would help that tells all involved parties what the matter is. Just one or two sentences? Turning bugs into features by documenting them:) Cheers,