> Regarding auto-extract, I see three possibilities:
> 1) Enhance Module::Pluggable to be smart about searching PARs
> 2) Add a "use PAR" flag to trigger full extraction
> 3) Add a flag to the par file itself to trigger full extraction
>
> I would be happiest with #3, I think. That is, if I know I'm
> packaging something that relies on a pluggable interface, I could set
> a flag so it will completely extract on load. Full extract a lot
> slower to boot than the incremental extract approach, so I don't
> think it should be the default.
>
> Would that per-par flag be feasible? Perhaps a flag in META.yml?
> That way it would be automatically backward compatible.
>
> Unfortunately, I don't have time to implement in the near future
> (baby due any day), but I'm very interested in this.
My guess is that additional flags in META.yml should be pretty safe. How
well they're honoured throughout the PAR code is another matter entirely,
though. I think I recall that the "clean" flag was always honoured.
If we went with route 3), we should think about a good interface for
editing and querying the PAR meta flags in .par's. I suppose it would be
reasonably straightforward to implement via PAR::Dist. (I already wrote
get_meta or so which returns the included META.yml as a string, I think.)
Additionally, there could be PAR::Dist::edit_meta or so which could be
used to toggle some flags such as "clean" or the extraction thing.
Options two and three can be combined, of course. With "use PAR {...
extract = 1};" overriding the META.yml flag... Now that we're certain
pre-extraction is a separate problem from the naming issue, I'm not as
opposed to new syntax any more.
Anyhow. I won't be reading the mailing list in the next 1-2 weeks and will
only read my mail occasionally.
Congratulations on your soon-to-be, new family member, Chris!
Steffen
