Skip Menu |
 

This queue is for tickets about the Module-Install CPAN distribution.

Report information
The Basics
Id: 18219
Status: open
Priority: 0/
Queue: Module-Install

People
Owner: Nobody in particular
Requestors: jpeacock [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: Critical
Broken in:
  • 0.52
  • 0.59
Fixed in: (no value)



Download (untitled) / with headers
text/plain 412b
Please see the second entry in this ticket: https://rt.cpan.org/Public/Bug/Display.html?id=14732 The problem is basically that the files in inc/Module/Install must not depend in any way with any version of Module::Install that might be already be installed. Otherwise, module users might work fine but module authors will have fits. I'm currently trying to replicate this with the 0.61 release of M::I. John
Subject: Re: [rt.cpan.org #18219]
Date: Sat, 18 Mar 2006 13:36:07 +1100
To: bug-Module-Install [...] rt.cpan.org
From: Adam Kennedy <adam [...] phase-n.com>
Download (untitled) / with headers
text/plain 1.7k
via RT wrote: Show quoted text
> Fri Mar 17 10:22:14 2006: Request 18219 was acted upon. > Transaction: Ticket created by JPEACOCK > Queue: Module-Install > Subject: (No subject given) > Owner: Nobody > Requestors: JPEACOCK@cpan.org > Status: new > Ticket <URL: http://rt.cpan.org/Ticket/Display.html?id=18219 > > > > Please see the second entry in this ticket: > > https://rt.cpan.org/Public/Bug/Display.html?id=14732 > > The problem is basically that the files in inc/Module/Install must not > depend in any way with any version of Module::Install that might be > already be installed. Otherwise, module users might work fine but > module authors will have fits. > > I'm currently trying to replicate this with the 0.61 release of M::I.
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
Subject: Re: [rt.cpan.org #18219]
Date: Sun, 19 Mar 2006 11:12:54 -0500
To: bug-Module-Install [...] rt.cpan.org
From: John Peacock <jpeacock [...] rowman.com>
Download (untitled) / with headers
text/plain 1.2k
adam@phase-n.com via RT wrote: Show quoted text
> 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.
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
Subject: Re: [rt.cpan.org #18219]
Date: Mon, 20 Mar 2006 05:06:45 +1100
To: bug-Module-Install [...] rt.cpan.org
From: Adam Kennedy <adam [...] phase-n.com>
Download (untitled) / with headers
text/plain 1.4k
It's already covered elsewhere. inc::Module::Install is only installed for authors. The inc/Module/Install.pm that gets loaded otherwise is Module::Install. Adam K John Peacock via RT wrote: Show quoted text
> Queue: Module-Install > Ticket <URL: http://rt.cpan.org/Ticket/Display.html?id=18219 > > > adam@phase-n.com via RT wrote:
>> 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.
> > 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 >
Download (untitled) / with headers
text/plain 842b
Show quoted text
> inc::Module::Install is only installed for authors.
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?
Subject: Re: [rt.cpan.org #18219] Interactions between inc/Module/Install and installed Module::Install
Date: Mon, 3 Nov 2008 09:13:31 +1100
To: bug-Module-Install [...] rt.cpan.org
From: "Adam Kennedy" <adamkennedybackup [...] gmail.com>
Download (untitled) / with headers
text/plain 1.4k
Huh? It should be utterly irrelevant. IF you are building a pre-packaged and uploaded tarball, it will use the bundled version. IF you are using an svn checkout, it will use the one on the system. If you are building a pre-packaged tarball, and it DOES try to load the system version, the installed inc::Module::Install module recognises this, and defers to the bundled version anyway. Adam K 2008/11/2 Andreas Koenig via RT <bug-Module-Install@rt.cpan.org>: Show quoted text
> Queue: Module-Install > Ticket <URL: http://rt.cpan.org/Ticket/Display.html?id=18219 > >
>> inc::Module::Install is only installed for authors.
> > 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? > >
Download (untitled) / with headers
text/plain 521b
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,


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.