Bug #20273 for CPAN: cpan install $module

Tue Jul 04 10:25:55 2006 Guest - Ticket created

Subject:

cpan install $module

This url describes the problem. http://www.unixwiz.net/archives/2005/09/dumb_software_c_1.html. Basically, junoscript includes a module called 'install'. So, running cpan install Foo tries to build 'install' and 'Foo'. Perhaps 'install' should be a reserved word?

Tue Jul 04 10:40:43 2006 Guest - Correspondence added

From:

Kenny Gatdula <kennyg [...] pobox.com>

On Tue Jul 04 10:25:55 2006, guest wrote: Show quoted text

> This url describes the problem. > http://www.unixwiz.net/archives/2005/09/dumb_software_c_1.html. > Basically, junoscript includes a module called 'install'. So, running > cpan install Foo tries to build 'install' and 'Foo'. Perhaps 'install' > should be a reserved word?

Patch adds install as a valid option.

--- cpan.orig 2006-07-04 10:33:57.000000000 -0400 +++ cpan 2006-07-04 10:35:34.000000000 -0400 @@ -187,6 +187,7 @@ 'i' => 'install', 'm' => 'make', 't' => 'test', + 'install' => 'install', ); my @CPAN_OPTIONS = grep { $_ ne $Default } sort keys %CPAN_METHODS; @@ -210,7 +211,7 @@ i => [ \&_default, 1, 0, 'Running `make install`' ], 'm' => [ \&_default, 1, 0, 'Running `make`' ], t => [ \&_default, 1, 0, 'Running `make test`' ], - + install => [ \&_default, 1, 0, 'Running `make install`' ], ); my %Method_table_index = ( @@ -245,7 +246,7 @@ ref $Method_table{$option}[ $Method_table_index{code} ] eq ref sub {}; print "$Method_table{$option}[ $Method_table_index{description} ] " . - "-- ignoring other opitions\n" if $option_count > 1; + "-- ignoring other options\n" if $option_count > 1; print "$Method_table{$option}[ $Method_table_index{description} ] " . "-- ignoring other arguments\n" if( @ARGV && ! $Method_table{$option}[ $Method_table_index{takes_args} ] );

Tue Jul 04 10:40:45 2006 The RT System itself - Status changed from 'new' to 'open'

Sat Jul 22 05:11:13 2006 andreas.koenig.gmwojprw [...] franz.ak.mind.de - Correspondence added

CC:	brian d foy <comdog [...] panix.com>
Subject:	Re: [rt.cpan.org #20273] cpan install $module
Date:	Sat, 22 Jul 2006 11:10:36 +0200
To:	bug-CPAN [...] rt.cpan.org
From:	andreas.koenig.gmwojprw [...] franz.ak.mind.de (Andreas J. Koenig)

Show quoted text

>>>>> On Tue, 4 Jul 2006 10:40:45 -0400 (EDT), "Guest via RT" <bug-CPAN@rt.cpan.org> said:

Show quoted text

> Queue: CPAN > Ticket <URL: http://rt.cpan.org/Ticket/Display.html?id=20273 >

Show quoted text

> On Tue Jul 04 10:25:55 2006, guest wrote:

>> This url describes the problem. >> http://www.unixwiz.net/archives/2005/09/dumb_software_c_1.html. >> Basically, junoscript includes a module called 'install'. So, running >> cpan install Foo tries to build 'install' and 'Foo'. Perhaps 'install' >> should be a reserved word?

Show quoted text

> Patch adds install as a valid option.

Brian, would you mind taking care of this ticket? I don't know how to transfer the ownership over to you. I'm in the mood to make a new CPAN.pm release (and hopefully will make it in the next days). -- andreas

Thu Aug 17 14:17:51 2006 bdfoy [...] cpan.org - Correspondence added

I don't like the change because it would require extensive special case handling to allow users to do what I don't intend them to do. Furthermore, the patch does not actually add the feature because it does not modify the script to properly handle the argument list. I somehow suspect that the change was not actually tested. Although people want to add "install" as a valid option, I don't want to add all of the cpan shell commands as options. By letting part of the shell interface leak out to my tool, other users will then expect other shell options to work too. Additionally, the patch is incomplete and does not work. Option handling is done by Getopt::Std which does not handle long opts or opts without a leading dash. The patch does not fix this for the suggested change. I'm not willing to consider broken code for a feature I don't even think is a good idea and that I don't want. I thought about adding something to detect if the first argument is "install" and die if it is (to train users properly), but I'm not sure that's a good idea either. This only comes up because the junoscript distro indexes a script called install, which I think may need to be fixed (probably by the distro author).

Tue Aug 22 20:02:40 2006 mschwern [...] cpan.org - Correspondence added

On Thu Aug 17 14:17:51 2006, BDFOY wrote: Show quoted text

> I don't like the change because it would require extensive special case > handling to allow users to do what I don't intend them to do.

I would argue that while it is your software, to be most useful to the user it is more important to consider what the user intends to do, not the designer. The designer is not there to tell the user what he intends, only the device (the cpan script and its docs) is. So you have two choices to reduce user error. A) alter the device to better convey your intended use to the user. B) alter the device to better fit the user's intended use. The below is going with B. Show quoted text

> Although people want to add "install" as a valid option, I don't want to > add all of the cpan shell commands as options. By letting part of the > shell interface leak out to my tool, other users will then expect other > shell options to work too.

Why not add all the cpan commands? If the syntax mirrors the shell ("cpan install Foo::Bar", "cpan force install Baz") then it should all be pretty self explainatory for the user and a simple pass through in the code. No more remembering what switch maps to what shell command and what subset of commands are available from the command line. Backwards compatibility isn't nearly as big a deal with a human-driven command line script. Humans can adapt. A simple heuristic such as this should help users change their behaviors... if( first argument is not a valid command and no switches provided ) { print qq['cpan @args' is better written as 'cpan install @args']; unshift @args, 'install'; } I'll whip something up.

Wed Aug 23 02:35:16 2006 andreas.koenig.gmwojprw [...] franz.ak.mind.de - Correspondence added

Subject:	Re: [rt.cpan.org #20273] cpan install $module
Date:	Wed, 23 Aug 2006 08:35:00 +0200
To:	bug-CPAN [...] rt.cpan.org
From:	andreas.koenig.gmwojprw [...] franz.ak.mind.de (Andreas J. Koenig)

Show quoted text

>>>>> On Tue, 22 Aug 2006 20:02:41 -0400, "Michael_G_Schwern via RT" <bug-CPAN@rt.cpan.org> said:

Show quoted text

> if( first argument is not a valid command > and no switches provided ) > { > print qq['cpan @args' is better written as 'cpan install @args']; > unshift @args, 'install'; > }

So when I add a command to CPAN::Shell, cpan program alters behaviour? That would be a bad idea. Seems to me similar to abbreviation support for commandline options, it leads to unpredictable behaviour. Did this version of CPAN.pm support the "version" command? If yes, then I have to say 'cpan install version'! Otherwise I can say 'cpan version'. -- andreas

Sat Sep 02 19:05:40 2006 mschwern [...] cpan.org - Correspondence added

On Wed Aug 23 02:35:16 2006, andreas.koenig.gmwojprw@franz.ak.mind.de wrote: Show quoted text

> >>>>> On Tue, 22 Aug 2006 20:02:41 -0400, "Michael_G_Schwern via RT"

> <bug-CPAN@rt.cpan.org> said: >

> > if( first argument is not a valid command > > and no switches provided ) > > { > > print qq['cpan @args' is better written as 'cpan install

> @args'];

> > unshift @args, 'install'; > > }

> > So when I add a command to CPAN::Shell, cpan program alters behaviour? > That would be a bad idea. > > Seems to me similar to abbreviation support for commandline options, > it leads to unpredictable behaviour. > > Did this version of CPAN.pm support the "version" command? > > If yes, then I have to say 'cpan install version'! > > Otherwise I can say 'cpan version'.

The idea is to deprecate and ween users off the current "cpan module_to_install" syntax and get them to use "cpan install module_to_install" instead. The current syntax is only left in to help the user's transition. The behavior will be actively discouraged with a warning every time they use it. The only case in which this fails is when * The user has not run "cpan" to install a module since the syntax change and thus has not yet seen the syntax change message * AND the user has installed a version of CPAN.pm which adds a new keyword * AND the user tries to install a module with the same name as that keyword. That's a pretty slim edge case. And the most likely thing the user will do next will self-correct. They will likely try to install a different module "cpan Some::Module", see the message about the syntax change, realize what happened and change their behavior.

Sun Sep 03 05:01:52 2006 andreas.koenig.gmwojprw [...] franz.ak.mind.de - Correspondence added

CC:	brian.d.foy [...] gmail.com
Subject:	Re: [rt.cpan.org #20273] cpan install $module
Date:	Sun, 03 Sep 2006 11:01:29 +0200
To:	bug-CPAN [...] rt.cpan.org
From:	andreas.koenig.gmwojprw [...] franz.ak.mind.de (Andreas J. Koenig)

Show quoted text

>>>>> On Sat, 02 Sep 2006 19:05:40 -0400, "Michael_G_Schwern via RT" <bug-CPAN@rt.cpan.org> said:

Show quoted text

> The idea is to deprecate and ween users off the current "cpan > module_to_install" syntax and get them to use "cpan install > module_to_install" instead. The current syntax is only left in to help > the user's transition. The behavior will be actively discouraged with a > warning every time they use it.

Now I get it and I understand that it is feasible. But I would leave the final judgement to brian. It is his code and I have never used "cpan" with an argument myself, so I don't miss anything and cannot make up my mind which syntax I would prefer if I'd use it. -- andreas

Sun Sep 03 11:27:37 2006 bdfoy [...] cpan.org - Correspondence added

On Tue Aug 22 20:02:40 2006, MSCHWERN wrote: Show quoted text

> On Thu Aug 17 14:17:51 2006, BDFOY wrote:

> > I don't like the change because it would require extensive special case > > handling to allow users to do what I don't intend them to do.

Show quoted text

> I would argue that while it is your software, to be most useful to the > user it is more important to consider what the user intends to do, not > the designer.

I understand the argument. However, if someone wants a tool to be a one shot cpan shell command they'll have to write it themselves. The argument handling will be completely different than the tool I've made, and since I personally don't want to have to type the extra "install " for the most common use case, I'm not going to be the one to write the code to do it. The most common uses should require the least work. Furthermore, I don't want to necesaarily tie my tool to any particular backend. If I decided to use CPANPLUS or something else, I want my tool to have the same interface. If Andreas feels like he wants to choose another tool over mine, or that this goal means it shouldn't be part of the CPAN.pm package, that's fine too. If someone wants to rewrite the tool to have a different interface, they are free to do so. It's going to be almost a complete rewrite though since the argument handling will be completely different. The provided patch did not address any of that. Since none of that scratches any itches I have, I won't be working on that. I think, however, that most of the problem is the junoscript package which indexs "install". That's the only reason I'e seen people complain about this. People could easily learn to not type "install " if PAUSE didn't think it was a module.

Mon Sep 11 15:15:24 2006 ANDK [...] cpan.org - Status changed from 'open' to 'rejected'