The full documentation of the module can be found in the lxc.pod file available on the module repo.
I have some direct questions to ask, but feel free to comment even about points I don't mentioned ;-)
My questions are :
How should I name this module ? At the beginning, I was thinking of Linux::Virt::LXC, but it seems that Linux::Virt is a “reserved” namespace for the already existing Linux::Virt module. The same occurs with Sys::Virt. Is thus ok to simply name it Virt::LXC ? I guess not because we lost the notion that this module is only designed to work on Linux, but I don't know what other to choose.
My module relies on lxc-* commands that should already be installed on the host. How should I manage the loading of the module in a environment that has those commands missing? Is it a good practice to directly bring the module into a failure (by returning something else than 1 at its importation)?
I wrote a (quite messy…) test file that is heavy to run because it has to create real LXC containers on the system that run the tests. Because of that, I choose to put them in the test folder reserved to developers (xt/) is it a good way to do?
I am using Log::Any for debugging and monitoring purpose. Is it ok to use it directly in this public module, or should I remove the log management and create a personal wrapper that will manage them? The thing is that Log::Any seems to be quite light and that some users of the lib will probably find it convenient. On the other hand, another group of users will probably be annoyed because they maybe had planned to log stuff differently. :-/
That's all for me! I'm now trying to lean how to manage the deployment with Dist::Zilla, and waiting for your answers. Thank for your help!