in reply to Re: Module::Metadata
in thread Module::Metadata

Your format would require the module to be installed everywhere where you want to use the module. If you put the data into POD, then you only need some module for their extraction if you really want the metadata.
Hmm, that's a good point. OTOH, if you're worried about not having the module, it's always possible to support something like this: 
eval {
    register Module::Metadata
             ...
};

[download]
That way it doesn't even try to save the metadata unless the module is already loaded.

There's also the question of the version number. If you give Module::Metadata the version number, presumably it should set $VERSION so you can say use Module 1.0.

I haven't thought out all the implications of this, but I could provide a "micro" implementation of this module that searched for the full version elsewhere in @INC and, if it couldn't find it, just set up the version number. Such a module would be perhaps a kilobyte.

=cut
--Brent Dax
There is no sig.

Replies are listed 'Best First'.
Re^3: Module::Metadata
by Aristotle (Chancellor) on Jan 11, 2003 at 17:24 UTC
    BEGIN eval require or similar constructs are a solution, but IMHO that gets in the way of laziness. On the other hand, every good module should have at least a minimum of POD, and the metadata, conceptually, is nothing other than documentation. So it'd be only natural to store it in the POD, which I'm going to write anyways. After some thinking, it seems to me the format could be very simple - rather than cooking up some special syntax, just use the key => value, list you intended for Module::Metadata's import to expect. It would effectively be a section of POD-commented-out Perl code - something like this: 
    =begin metadata

    author  => 'BRENTDAX',
    version => 0.01,
    license => 'perl',
    threads => 'none',
    thrsafe => 'unknown',
    depends => {
        perl => 5.005
    },

=end metadata

    [download]
    Note how this also eliminates the source filtering headaches since a POD parser can unambiguously extract the section, unlike any manual attempts to find the semicolon which terminates a use statement. The data found could be revaled just as per the example in your other post. A metadata-aware POD browser could effortlessly present this information along with the documentation, too.

    Makeshifts last the longest.

[reply]
[d/l]
      As mentioned before, this is a problem with use Module VERSION. OTOH, this *would* clear up the problems with not having the module installed...

      =cut
      --Brent Dax
      There is no sig.

[reply]
[d/l]

In Section Meditations