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

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

Thread Previous | Thread Next
Stas Bekman
March 27, 2003 19:38
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 --->

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About