> > >> cpan --install pler > > But that includes a lib/pler.pm.
You have cause and effect the wrong way around, I renamed the main application module as lib/pler.pm specifically so that "cpan --install pler" would Do What I Meant. >I have this ugly suspicion, however, that we aren't going to solve > > this problem with yet another namespace. > > Yep. Looking at how CPAN.pm and CPANPLUS.pm are both assuming modules > in their queries (not allowing distro names), we either have to redo > the index or redo the index. (I'm guessing that pause won't put the > distro in the index without a .pm file -- though maybe program_name in > the META.yml will handle that.) Or we redo the way that both CPAN and CPANPLUS interpret "install foo" to search for BOTH module names and some new(perhaps) notional "script" name. >When it comes to command line apps, part of our problem comes from > >downstream with the distro packagers. If we end up with something > > like... > > > >> apt-get install libbin-foo-perl > > > >... instead of just ... > > > >> apt-get install foo > > I think we can handle that in META.yml, no? > Maaaaybe, although we can't recommend the name of the resulting package, because different distros have their own naming conventions. Some notional META.yml key that identifies a package as an app rather than a library would problem be enough to then modify the transformed package name. So instead of foo -> libfoo-perl or perl(libfoo) they would just foo -> foo if they saw "type: application" etc etc... Adam K
