Re: When CPAN shell cannot find a module
On Mon, 21 Nov 2005, Ken Williams wrote: Think about what would happen if Satan uploaded a malicious distribution called PathTools with a higher version number than mine. You'd want the whole world to get Satan's distribution by default, just so they can save a couple keystrokes? Any ambigious situations such as that could easily be handled by asking the user KWILLIAMS and SATAN both are providing PathTools, which would you like? or having it spit out a list of choices and let the user implicitly pick by then doing the install AUTH/dist...gz at that point. Is there some REAL chance of harm in what we're talking about here that couldn't be trivially ameliorated such as here? My previous suggestion of having an explicit mapping would help avoid getting the wrong person's PathTools. It wouldn't have to track versions in the map since PathTools could map to KWILLIAMS/PathTools and determine the latest from that. And as I pointed out the issue here isn't merely distnames, but common misimpressions. Being able to install Template::Toolkit won't cause the universe to blow-up. Also, lack of distname support is overblowing the situation. Distnames are supported perfectly fine as long as you put it in the proper syntax with author's ID and version. The proper syntax in this case is unnecessarily complex and utterly nonobvious to all but the Perl cognescenti. That seems a pretty harsh way to treat sysadmins stuck with installing Perl-based applications who may have no prior Perl experience whatsoever. If there were some real harm in making it easier it might make sense to me, but maybe somebody can share with me something that's not a red herring that will help me get it. -- /chris My aim is to agitate and disturb people. I'm not selling bread, I'm selling yeast. - Miguel de Unamuno, writer and philosopher (1864-1936)
Re: When CPAN shell cannot find a module
Well, I'm glad someone brought this up. I've always gotten the CPAN shell's i and install commands mixed up and have often wanted to pass a distribution name to it. First, the online help (? command) and error messages are not entirely helpful. Second, i appears too much like a shortcut for install. And third, the CPAN shell's install command very much resembles ActiveState's PPM install command, but the latter expects you to specify a distribution name and also has i as a shortcut (you can see why one would get confused): = ppm install DBIx-Simple # or i DBIx-Simple # --installs distribution ppm install DBIx::Simple Searching for 'DBIx::Simple' returned multiple results. Using 'search' instead.. Searching in Active Repositories 1. DBIx-Simple [1.26] Easy-to-use OO interface to DBI 2. DBIx-Simple-OO [0.01] Retrieve database rows as objects 3. DBIx-Simple-OO [0.01] Retrieve database rows as objects 4. DBIx-SimpleQuery [0.02] Query databases using as little code as possible 5. DBIx-SimpleQuery [0.02] Query databases using as little code as possible = The other gripes I've had about the CPAN shell are it's verbosity (e.g. tons of meaningless messages like LWP not available), the cumbersomeness in figuring out how to fix a broken urllist, and the sheer number of questions it asks you when you go to first configure it. I don't want to specify that my pager will be /usr/bin/less. In fact, I don't want to configure anything. I just want to say install ABC-XYZ (much like PPM), and _iff_ there is any ambiguity, then prompt me with suggestions (help me out a little). All-in-all, it seems that a simple thing like this should be simple: I just want to install ABC-XYZ (i.e. the latest version of this distribution, and I don't care how you do it). I tried out CPANPLUS tonight, which I read is the next generation CPAN shell. I find some improvements here in terms of online help and reduced verbosity. Cygwin (www.cygwin.com) has an example of a fairly user-friendly installer. However, even this could be improved: it could ask fewer questions (or not repeat them every time it is run), and a search/filtering tool would be useful since the Cygwin package list is getting quite lengthy. --davidm Christopher Hicks wrote: On Mon, 21 Nov 2005, Ken Williams wrote: Think about what would happen if Satan uploaded a malicious distribution called PathTools with a higher version number than mine. You'd want the whole world to get Satan's distribution by default, just so they can save a couple keystrokes? Any ambigious situations such as that could easily be handled by asking the user KWILLIAMS and SATAN both are providing PathTools, which would you like? or having it spit out a list of choices and let the user implicitly pick by then doing the install AUTH/dist...gz at that point. Is there some REAL chance of harm in what we're talking about here that couldn't be trivially ameliorated such as here? My previous suggestion of having an explicit mapping would help avoid getting the wrong person's PathTools. It wouldn't have to track versions in the map since PathTools could map to KWILLIAMS/PathTools and determine the latest from that. And as I pointed out the issue here isn't merely distnames, but common misimpressions. Being able to install Template::Toolkit won't cause the universe to blow-up. Also, lack of distname support is overblowing the situation. Distnames are supported perfectly fine as long as you put it in the proper syntax with author's ID and version. The proper syntax in this case is unnecessarily complex and utterly nonobvious to all but the Perl cognescenti. That seems a pretty harsh way to treat sysadmins stuck with installing Perl-based applications who may have no prior Perl experience whatsoever. If there were some real harm in making it easier it might make sense to me, but maybe somebody can share with me something that's not a red herring that will help me get it.
Re: When CPAN shell cannot find a module
Also, lack of distname support is overblowing the situation. Distnames are supported perfectly fine as long as you put it in the proper syntax with author's ID and version. I think the problem Jim encountered is that proper syntax is part of the arcana of CPAN. It's not obvious from the help: a,b,d,m WORD or /REGEXP/ about authors, bundles, distributions, modules iWORD or /REGEXP/ about anything of above rNONE reinstall recommendations ls AUTHORabout files in the author's directory Something that clarifies that AUTHOR/DIST-VERSION is a valid format would help. Or rather, some specific example of what that WORD can be: where WORD is either a module, bundle or author name or a distribution name of the form AUTHOR/DISTRIBUTION-VERSION It's vaguely alluded to in the CPAN perldoc, but only in the section describing the four CPAN::* classes. A doc patch would be a quick fix for this. Regards, David Golden
Re: When CPAN shell cannot find a module
On Sun, 20 Nov 2005 14:51:42 -0500, James E Keenan [EMAIL PROTECTED] said: I'm wondering if my diagnosis of the following annoying problem is correct. When I use the CPAN shell to install a distribution which does not include a package with the name of the distribution, the shell immediately tells me to use the 'i /distroname/' to find objects with matching identifiers. If information on the distribution is located, then I have to guess as to which module within the distribution is one that I don't have up-to-date and which will therefore trigger the shell to proceed with installation. Example: Just now I saw on perl.cpan-testers that Ken Williams had uploaded a distribution named PathTools. As you did know the authors name, you could have asked immediately cpan ls kwilliams and would have got the exact distribtion name: 112124 2005-11-18 KWILLIAMS/PathTools-3.14.tar.gz From there you would have just said cpan install KWILLIAMS/PathTools-3.14.tar.gz and would have got it. Alternatively (my favorite) you could have used the 'r' command and it would have reported something like this: Cwd3.05 3.14 K/KW/KWILLIAMS/PathTools-3.14.tar.gz and then an 'install Cwd' would have had success. I checked it out at search.cpan.org and decided to install it. Here is an edited transcript of my shell session: [...snip...] So I eventually get the shell to work ... but I really don't see why it couldn't handle 'install PathTools' right from the get-go? Anyone know why? Is there a workaround? Thanks. CPAN shell is very cautious not to install the wrong thing. It wants to be absolutely sure that it installs the thing that you wanted. Witness: cpan install /^Cwd$/ Sorry, install with a regular expression is not supported I don't think many people would appreciate getting something installed they didn't explicitly ask for. -- andreas
Re: When CPAN shell cannot find a module
Randy Kobes wrote: On Sun, 20 Nov 2005, James E Keenan wrote: [snip] Note that, if you know the distribtion you want to install, CPAN.pm understands cpan install KWILLIAMS/PathTools-3.14.tar.gz That's the step I was looking for: what to do once the 'i /somemodule/' command returns a results. Thanks, Randy and Andreas. jimk
Re: When CPAN shell cannot find a module
On Sun, 20 Nov 2005, Andreas J. Koenig wrote: I don't think many people would appreciate getting something installed they didn't explicitly ask for. Hmmm. I can have extra pain every time I'm installing something to avoid occassionally getting something I don't want or I can have pain every thousandth time I install something because oopsie I got something extra. It doesn't seem like a hard choice to me. Let's just say your many people aren't the same folks as my any people. ;-) The lack of distname support due to anal retentive accident avoidance in CPAN is utterly odd considering the culture of DWIMery that is so much a part of Perl. I'm not surprised that one person would think this was good, but the whole Perl community acquiescing to it is quite a shock. -- /chris Documentation is like sex: when it is good, it is very, very good; and when it is bad, it is better than nothing. -- Dick Brandon Physics is like sex. Sure, it may give some practical results, but that's not why we do it. -- Richard Feynman, physicist and Nobel laureate
Re: When CPAN shell cannot find a module
On Nov 21, 2005, at 10:51 AM, Christopher Hicks wrote: On Sun, 20 Nov 2005, Andreas J. Koenig wrote: I don't think many people would appreciate getting something installed they didn't explicitly ask for. Hmmm. I can have extra pain every time I'm installing something to avoid occassionally getting something I don't want or I can have pain every thousandth time I install something because oopsie I got something extra. It doesn't seem like a hard choice to me. Let's just say your many people aren't the same folks as my any people. ;-) The lack of distname support due to anal retentive accident avoidance in CPAN is utterly odd considering the culture of DWIMery that is so much a part of Perl. I'm not surprised that one person would think this was good, but the whole Perl community acquiescing to it is quite a shock. Chris, If CPAN made it easy to install unintended software by mistake, that would be a huge security hole. Some people run cpan as root. Defensive programming is absolutely the right thing here. Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Re: When CPAN shell cannot find a module
On Mon, 21 Nov 2005, Chris Dolan wrote: If CPAN made it easy to install unintended software by mistake, that would be a huge security hole. Some people run cpan as root. Defensive programming is absolutely the right thing here. And how exactly would a shortcut that says oh you asked for something that isn't really a module name, would you like us to install THIS package which contains CERTAIN modules anyway? cause security issues? I run the cpan shell as root all the time. Its a pain to have to remember the CPAN caniptions every time I'm setting up a new random server and the less often you deal with it the more likely you will have forgotten it all. This is exactly the context where the sort of shortcut that Perl is known for should be eximplified but its not. It may be the individual's first exposure to the Perl world. Let's not make it suck because of weak fears. PathTools and Template Toolkit are both examples where the thing to type into CPAN isn't clear to the newbie sysadmins. If we had a list of things like that for the important modules that have such strangeness then there should be any security problem in doing this without prompting since those mappings would be official and Known To Be OK. If I say install TemplateToolkit or install Template::Toolkit having that map to install Template without too much fuss is not only harmless and significantly helpful it might even be a security benefit since I won't accidentally install three other templating things in the meantime hoping to find the right one. The amount of time saved for sysadmins all over the world without causing anyone one iota of actual harm is awe-inspiring. So, am I really missing something here? Is there really some chance for a harmful mistake being made that can't be trivially mitigated with solutions like I mentioned above? -- /chris There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. -- C.A.R. Hoare
Re: When CPAN shell cannot find a module
On Mon, 21 Nov 2005, Christopher Hicks wrote: On Mon, 21 Nov 2005, Chris Dolan wrote: If CPAN made it easy to install unintended software by mistake, that would be a huge security hole. Some people run cpan as root. Defensive programming is absolutely the right thing here. And how exactly would a shortcut that says oh you asked for something that isn't really a module name, would you like us to install THIS package which contains CERTAIN modules anyway? cause security issues? I run the cpan shell as root all the time. Its a pain to have to remember the CPAN caniptions every time I'm setting up a new random server and the less often you deal with it the more likely you will have forgotten it all. This is exactly the context where the sort of shortcut that Perl is known for should be eximplified but its not. It may be the individual's first exposure to the Perl world. Let's not make it suck because of weak fears. PathTools and Template Toolkit are both examples where the thing to type into CPAN isn't clear to the newbie sysadmins. If we had a list of things like that for the important modules that have such strangeness then there should be any security problem in doing this without prompting since those mappings would be official and Known To Be OK. If I say install TemplateToolkit or install Template::Toolkit having that map to install Template without too much fuss is not only harmless and significantly helpful it might even be a security benefit since I won't accidentally install three other templating things in the meantime hoping to find the right one. The amount of time saved for sysadmins all over the world without causing anyone one iota of actual harm is awe-inspiring. So, am I really missing something here? Is there really some chance for a harmful mistake being made that can't be trivially mitigated with solutions like I mentioned above? Andreas can correct me if I'm wrong, but I don't think PAUSE puts any restrictions on the base name of the distribution that appears in the PAUSE indices that CPAN.pm uses. This opens up a couple of scenarios that could potentially arise that would make the behaviour you propose either harmful or more complicated: - Someone registers a module MyModule that coincides with the base name of a distribution of another author. Then install MyModule within the CPAN.pm shell would be ambiguous - do you mean the module or the distribution? A different command other than install would have to be used for installing distributions. - Two authors happen to have a distribution with the same base name, containing different sets of modules. Then, install_distribtion DistName would be ambiguous which would require user input to resolve. In both cases an added layer of complexity would be involved so as CPAN.pm would install the right thing. This doesn't seem any easier (and, in fact, seems more prone to error) than the current cpan install KWILLIAMS/PathTools-3.14.tar.gz or, as Andreas mentioned, using CPAN.pm to get a list of recommended modules to update. -- best regards, randy kobes
Re: When CPAN shell cannot find a module
On Nov 21, 2005, at 10:51 AM, Christopher Hicks wrote: Hmmm. I can have extra pain every time I'm installing something to avoid occassionally getting something I don't want or I can have pain every thousandth time I install something because oopsie I got something extra. It doesn't seem like a hard choice to me. Let's just say your many people aren't the same folks as my any people. ;-) The lack of distname support due to anal retentive accident avoidance in CPAN is utterly odd considering the culture of DWIMery that is so much a part of Perl. I'm not surprised that one person would think this was good, but the whole Perl community acquiescing to it is quite a shock. Think about what would happen if Satan uploaded a malicious distribution called PathTools with a higher version number than mine. You'd want the whole world to get Satan's distribution by default, just so they can save a couple keystrokes? Also, lack of distname support is overblowing the situation. Distnames are supported perfectly fine as long as you put it in the proper syntax with author's ID and version. -Ken
When CPAN shell cannot find a module
I'm wondering if my diagnosis of the following annoying problem is correct. When I use the CPAN shell to install a distribution which does not include a package with the name of the distribution, the shell immediately tells me to use the 'i /distroname/' to find objects with matching identifiers. If information on the distribution is located, then I have to guess as to which module within the distribution is one that I don't have up-to-date and which will therefore trigger the shell to proceed with installation. Example: Just now I saw on perl.cpan-testers that Ken Williams had uploaded a distribution named PathTools. I checked it out at search.cpan.org and decided to install it. Here is an edited transcript of my shell session: # START from CPAN shell session # cpan install PathTools CPAN: Storable loaded ok Going to read /Users/jimk/.cpan/Metadata Database was generated on Fri, 18 Nov 2005 22:50:02 GMT Warning: Cannot install PathTools, don't know what it is. Try the command i /PathTools/ to find objects with matching identifiers. cpan i/PathTools/ Unknown command 'i/PathTools/'. Type ? for help. cpan i /PathTools/ Distribution id = K/KW/KWILLIAMS/PathTools-3.14.tar.gz CPAN_USERID P5P (The Perl5 Porters Mailing List perl5-porters@perl.org) CONTAINSMODS File::Spec::Win32 File::Spec::Epoc File::Spec File::Spec::Unix File::Spec::OS2 File::Spec::VMS File::Spec::Functions File::Spec::Cygwin File::Spec::Mac Cwd [1st guess: File::Spec::VMS] cpan install File::Spec::VMS File::Spec::VMS is up to date. [Oops, that didn't work! ] cpan install File::Spec::Cygwin File::Spec::Cygwin is up to date. [Oops, that didn't work! ] cpan install File::Spec::Epoc File::Spec::Epoc is up to date. [I noticed that File::Spec's version is the same as that of this new PathTools -- 3.14 -- and decide to guess that. ] cpan install File::Spec [Success at last! ] Running install for module File::Spec Running make for K/KW/KWILLIAMS/PathTools-3.14.tar.gz CPAN: LWP::UserAgent loaded ok Fetching with LWP: http://www.cpan.org/authors/id/K/KW/KWILLIAMS/PathTools-3.14.tar.gz CPAN: Digest::MD5 loaded ok Fetching with LWP: http://www.cpan.org/authors/id/K/KW/KWILLIAMS/CHECKSUMS Checksum for /Users/jimk/.cpan/sources/authors/id/K/KW/KWILLIAMS/PathTools-3.14.tar.gz ok Scanning cache /Users/jimk/.cpan/build for sizes PathTools-3.14/ PathTools-3.14/Build.PL [and everything is cool from here on] # END from CPAN shell session # So I eventually get the shell to work ... but I really don't see why it couldn't handle 'install PathTools' right from the get-go? Anyone know why? Is there a workaround? Thanks. Jim Keenan
Re: When CPAN shell cannot find a module
On Sun, 20 Nov 2005, James E Keenan wrote: I'm wondering if my diagnosis of the following annoying problem is correct. When I use the CPAN shell to install a distribution which does not include a package with the name of the distribution, the shell immediately tells me to use the 'i /distroname/' to find objects with matching identifiers. If information on the distribution is located, then I have to guess as to which module within the distribution is one that I don't have up-to-date and which will therefore trigger the shell to proceed with installation. Example: Just now I saw on perl.cpan-testers that Ken Williams had uploaded a distribution named PathTools. I checked it out at search.cpan.org and decided to install it. Here is an edited transcript of my shell session: # START from CPAN shell session # cpan install PathTools CPAN: Storable loaded ok Going to read /Users/jimk/.cpan/Metadata Database was generated on Fri, 18 Nov 2005 22:50:02 GMT Warning: Cannot install PathTools, don't know what it is. Try the command i /PathTools/ to find objects with matching identifiers. cpan i /PathTools/ Distribution id = K/KW/KWILLIAMS/PathTools-3.14.tar.gz CPAN_USERID P5P (The Perl5 Porters Mailing List perl5-porters@perl.org) CONTAINSMODS File::Spec::Win32 File::Spec::Epoc File::Spec File::Spec::Unix File::Spec::OS2 File::Spec::VMS File::Spec::Functions File::Spec::Cygwin File::Spec::Mac Cwd [1st guess: File::Spec::VMS] cpan install File::Spec::VMS File::Spec::VMS is up to date. [Oops, that didn't work! ] [ .. ] [I noticed that File::Spec's version is the same as that of this new PathTools -- 3.14 -- and decide to guess that. ] cpan install File::Spec [Success at last! ] Running install for module File::Spec Running make for K/KW/KWILLIAMS/PathTools-3.14.tar.gz [ ... ] # END from CPAN shell session # So I eventually get the shell to work ... but I really don't see why it couldn't handle 'install PathTools' right from the get-go? Anyone know why? Is there a workaround? Thanks. One reason for this behaviour, I think, is that CPAN.pm, and the CPAN/PAUSE indices, are designed so that module names are unique, in that there is a single distribution containing the most recent version of a given module. So one can say cpan install File::Spec and CPAN.pm knows that KWILLIAMS/PathTools-3.14.tar.gz is the relevant distribution to fetch. That's not the same with distribution names - I believe it would be possible (though certainly not recommended) for an author other than KWILLIAMS to upload their own distribtion called PathTools-x.yz.tar.gz, containing a completely different set of modules. Then, as long as that author had the proper permissions for this set of modules, the CPAN/PAUSE indices would then associate this other PathTools distribution with this set of modules. Although CPAN.pm I think can live with non-unique distribution names across different authors, it would probably cause problems with search.cpan.org; for example, http://search.cpan.org/dist/PathTools right now points to KWILLIAMS/PathTools-3.14. Note that, if you know the distribtion you want to install, CPAN.pm understands cpan install KWILLIAMS/PathTools-3.14.tar.gz -- best regards, randy kobes
