For those that missed it's release let me also mention that "pip" is out now.

http://search.cpan.org/~adamk/Module-Plan-Base-0.04/lib/pip.pm

This extends the Bundle idea to third party or arbitrary (such as backpan or whatever) modules.

I wrote it because I wanted to install a specific set of third party distributions, but have their dependencies able to recurse across the CPAN/third-party boundary and install CPAN modules.

The default script format lets you mix "CPAN::Module", "CPAN/Dist-1.00.tar.gz" and "./Third-Party-1.00.tar.gz" installs together.

Shortly I plan to also extend this to also support "http://anyserver.com/Anything-1.00.tar.gz"; as well.

Relative paths are also relative to the script.p5i file, so if it says to install ./whatever-1.00.tar.gz and you have run

> pip http://anywerver.com/default.p5i

... it will pull the dists from relative URIs.

It's written the way it is so that you don't have to have a minicpan install or some sort of server setup. It works directly with the CPAN client setup.

And it should work with every Perl back to 5.005.

It may not be entirely what you want (which I suspect is a way of running your repository where you have some control over the versions in the index) but it SHOULD allow you to build install scripts on a per-application basis (if your own apps are built as CPAN-like dists).

After URI support, I'd like to add .p5z compilation support, which will grab all the modules listed in the .p5i file, and combine them to form a basic zip file.

Please note this is NOT like PAR, which as I understand it is for binary packs. This is specifically for source packs. And if a platform-specific dependency is missing from the pack, it should still recurse to CPAN as normal.

Adam K

Gabor Szabo wrote:
I am not exactly sure this is the appropriate place to raise this idea
but it relates very strongly to quality of CPAN modules.


Occasionally new version of CPAN modules break code in applications.
We cannot catch that, but we can at least catch cases when it breaks
other CPAN modules.

There are many people who would like to use only stable versions
of CPAN modules to some definition of stable. For lack of better
definition I might define stable as
'not breaking other important CPAN module'.

I would like to be able to setup a system where I can mark a set
of module/version pairs with a flag and version number.
(e.g. I would use szabgab_1, szabgab_2...)

Then when someone installs a module she would be able
to configure CPAN.pm to only install modules with a specific version
number of that specific flag (e.g only szabgab_1).
Modules without such flag could be installed only by force.
A module that has such a flag will be installed at the given version of the
module.

E.g. I just spent some time figuring out that my applications broke
because DBD::SQLite 1.13 broke Class::DBI.
If we had that system in place my flag (szabgab_1) would still point
to DBD::SQLite 1.12. Then anyone using my flag would be (reasonably)
safe upgrading DBD::SQLite as I am going to advance the flag
on DBD::SQLite only once I tested it works with Class::DBI.


Others might also create such flags for modules they need.
We might also be able to cooperate and manage a common flag that
covers most of CPAN.

The mapping of flag to Module-Version pairs could actually reside on any
server with ftp or http access. CPAN.pm would be configured to use such
a URL.

What do you think?

Gabor

Reply via email to