Front page | perl.perl5.porters |
Postings from March 2003
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:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com