develooper Front page | perl.perl5.porters | Postings from March 2003

Re: rfc: a generic solution for dual-life CPAN packages

Stas Bekman
March 27, 2003 19:28
Re: rfc: a generic solution for dual-life CPAN packages
Message ID:
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/  # but exclude lib/
+lib2/     # expose lib2/

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/  # exclude lib/

Of course it may support globbing as well. e.g. -lib/*/*

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

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:

- 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     mod_perl Guide ---> Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About