Eric Wilhelm <[EMAIL PROTECTED]> writes: > [...] that things which will be installed in a directory named > "bin/" should have a namespace named "bin::"?
I want to clearly separate a CPAN location and a namespace. Small applications usually do not have (nor need) a private namespace. 'helloworld' is an application that on a *ix system would get installed into /usr/bin or /usr/local/bin, but it would be just 'helloworld', not 'bin::helloworld'. And it's package, if any, would most likely be 'main'. But this does not mean that apps like this cannot be archived in a pseudo-module-toplevel. I think we basically agree that choosing a new pseudo-toplevel would be good to avoid confusion. That rules out App. I think Application would be the best alternative. Complaints that this is too long should be directed to /dev/void. This is the 21st century, my shells and editors all support completion. Some other 'rough' conclusions as I see them emerge from the discussions: - Modules that have accompanying (supporting) tools stay as they are. No need to change LWP, Mail::SpamAssassin etc. A search engine (CPAN indexer?) could be helpful in finding applications that come with modules. - Applications that only use regular CPAN modules could go into the new Application location (not: namespace, see above). So the 'helloworld' kit would become Application-helloworld. The application itself stays 'helloworld'. - Application that have accompanying (supporting) modules currently have no choice other than to put the modules into the perl libraries, making them globally available to any perl application. If this is not desired (and I can think of many situations) an alternative is needed. Another thing is the format of an application kit. I already suggested to use the familiar .tar.gz format, just like module kits. An application kit should contain at least a README, MANIFEST, Makefile.PL and, of course, the application. For the hypothetical 'helloworld' program the kit would be named Application-helloworld-1.00.tar.gz, and contain: Application-helloworld-1.00/README Application-helloworld-1.00/MANIFEST Application-helloworld-1.00/Makefile.PL Application-helloworld-1.00/script/helloworld (I hate to use 'script' but this is what MakeMaker requires.) Where to put private modules? In a system that supports a standard (Linux, Open Desktop, Windows?) the local conventions should be used. But the current kit builders do not support anything like this. An alternative would be to put the modules under the Perl tree, in a pseudo-namespace Application::appname (where appname is the application name). Applications would then have to add a use lib Application::appname; to get at their private modules. In a way, this closes the circle by turning the applications plus supporting modules into modules with an accompanying application ;-). For outsiders, modules that reside under the Application hierarchy should be considered private and not be relied on. -- Johan
