The more I think about it the more I like my latest idea. I'm going to expand on it in this post as I think it may do more things than just solving the bundling problem.
What I'm proposing is to have a mechanism similar to /robots.txt in the HTTP protocol, where '/' is the root of the web server namespace So now we have "the CPAN indexer protocol" and we introduce /INDEX, where / is the top-level directory of a given package.
/INDEX provides a way for a package to tell the indexer what it wants to be exposed and/or what not. We can work out a simple syntax, like:
+lib/ # expose all packages under lib/ -lib/private.pm # but exclude lib/private.pm +lib2/Foo.pm # expose lib2/Foo.pm
Of course the simplest version is to just specify what modules are to be excluded (implying that the rest are to be included):
-inc/ # exclude all packages under inc -lib/private.pm # exclude lib/private.pm
Of course it may support globbing as well. e.g. -lib/*/*_private.pm
In the future we may introduce new syntax to have more ways for the package to talk to the indexer(s). e.g. we may have new indexers, which we may want to tell them different things (just like with HTTP robots).
Why this is beneficial to the /inc solution:
- it's flexible and not hardcoded, casted in stone, solution
- the developer has a full control over what it wants to be exposed and what not.
- the developer deciding to split one of the modules into a separate package, while keeping the include, only needs to add these modules to /INDEX. He doesn't have to change the filesystem layout, which is also a problem if cvs is used (losing history).
- the developer may decide to fold some dual-life package, back into its original source. Again only one file needs to be modified, no fs change is required.
- the developer may have a master module in a bigger package, and also distribute it separately on CPAN for user's convenience. Moving that master module into a special directory is not convenient at all, and while possible to do during 'make dist' it may cause problems during the build time, if some code was expecting to find the module in the original place.
- in certain cases /inc solution simply doesn't work. My package DocSet includes several examples, which can't live in /inc or /t. Unfortunately the indexer picks them up. e.g. it picks the example module DB_File::Lock2:
cpan> i /DB_File::Lock/ Module DB_File::Lock (D/DH/DHARRIS/DB_File-Lock-0.05.tar.gz) Module DB_File::Lock2 (S/ST/STAS/DocSet-0.15.tar.gz) 2 items found
If tomorrow someone else releases a real module DB_File::Lock2, user wanting to install it may install DocSet instead of that real package. Notice that in this case, the collision is not under control of the other author who has released the same package. I could have avoided it in first place if I could tell indexer not to index the example modules. Notice that the DocSet package has this module as: examples/site/src/docs/1.0/guide/code/DB_File-Lock2.pm
- indexer doesn't have to introduce a special solution for the perl-core, as it can list all the dual-life packages in that file. Then the perl-core is no longer restricted to put the dual-life package into a special dir.
- currently used hadrcoded solution using /inc is still supported, by simply adding /inc to /INDEX (-/inc)
- CPAN::MakeMaker only needs to include the bundled files in /INDEX and may put them under any dir it feels like.
-----
I don't really care how this special file is to be called, or what the inclusion/exclusion syntax is. the point is to have the functionality in place.
__________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
