It sounds like you are trying to do more than what Getopt::Euclid was designed to do.
Show quoted text> Currently Euclid has no public interface, that allow manually define
> list of file for parsing. Default functionality is not suitable for us,
> because we want manage CLI interfaces centralized from one point, not write
> use Getopt::Euclid in every needed package.
Did you try what I suggested earlier (from the manual)?
use Module1::Getopt (); # No argument parsing
use Module2::Getopt (); # No argument parsing
use Getopt::Euclid; # Arguments parsed
This means that you can put the declaration of some common arguments in Module1::Getopt and Module2::Getopt and reuse it in every module that needs it. I do not fully understand what you are trying to achieve, so that may or may not be an viable option for you.
Show quoted text> Second reason is that Euclid installs own import function - this
> produce conflicts with our packages code.
You can call Getopt::Euclid this way to avoid it importing:
use Getopt::Euclid ();
Again, that or may not be what you want.
Show quoted text> It would be nice if you implement this functionality, so we don't have
> to call private methods.
I am open to making some methods publicly available wherever that makes sense.
Show quoted text> Or simply write our $man; ))
By the way, I wanted to clarify that I cannot make $man global, because that would imply that if several scripts that use Getopt::Euclid were executed run simultaneously, they would overwrite each other's $man.
I suggest the following course of action. Clone the git development branch (0.2.x) of Getopt::Euclid (
http://sourceforge.net/p/getopt-euclid/code/ci/0.2.x/tree/) and try to code the features you need. It may also make sense to developing a new module that does exactly what you need. Feel free to have Getopt::Euclid as a dependency and use some of the internal methods if it makes sense. As mentioned above, I am open to making some internal methods publicly available, or even expose new ones if required.
Cheers,
Florent