I already uploaded two other modules Tk::Zinc and SVG::SVG2zinc. So I have now some little experience on it. However in the case of Ivy, the trad-off is between CPAN namespace pollution and preservation of our numerous existing applications. We can hardly get rid of 5 years of code, just to upload it to the CPAN. That's why I am looking for a wrapper technic or something similar to maintain the current Ivy.pm inhouse, while delivering a Xxx:Ivy on the CPAN.
You are right, the website is currently down, I pray it will be up again on Monday. Sorry for this.
| [reply] |
That should be easy given you've properly designed your ivy modules.
Make the switch to Xxx::Ivy,
and upon `perl Makefile.PL'
prompt (using ExtUtils::MakeMaker::prompt)
users if they wish to install legacy
Ivy module, which would do the neccessary mojo
so your apps don't break
( if your modules are written well, all that should be neccessary is a
#Ivy.pm
package Ivy;
use base 'Xxx::Ivy';
1;
). | [reply]
[d/l] |
(if your modules are written well, all that should be necessary is ... <snip>)
That'll work if the current Ivy interface is via class/object methods. However, if the current interface is via exported functions/symbols, then the above won't automatically be enough: the functions from Xxx::Ivy will likely only be exported up to Ivy, when really it's Ivy's caller who wants those functions.
dominus's ModuleBundle can shine light here, as can Exporter's export_to_level method.
blyman
setenv EXINIT 'set noai ts=2'
| [reply]
[d/l] |