Re: Module naming and a couple other questions
Thank you for your replies - here's a bit more info: 1. This is not something that only runs on Win32; in fact, I doubt it will run on Win32, as this uses the WMI code from the Samba project to support WMI on non-Win32 platforms. WMI is Windows Management Instrumentation (or something like that), and this is intended to let non-Win32 platforms interface with the WMI services that run on WIndows. Using Net:: as the top-level would work, as this is a wire protocol. 2. It sounds like given the single function and it's relative uniqueness, there's no problem exporting it by default other than not being able to change it later. For the sake of forward compatibility, I'll probably just put it in @EXPORT_OK and require its explicit import. 3. Since much of the code is already GPL (and a bunch of the code I wrote i modifications to that), I'll probably just distribute the whole thing as GPL, and make it simple. My code is pretty much worthless without the GPL code, so there's no real reason not to make it so. 4. I'll look into Module::Build and using prompt() - this whole project has been my first venture into building a packaged module (as opposed to something I just built for myself/internal use), so I started simple :). I'm not real keen on using Alien, despite its obvious usefulness in ensuring that the required source is available and configured properly. Given the limited audience for this module, I'm comfortable assuming that anyone who needs it can follow directions (even though I'm sure that'll bite me someday...). Thanks for the input - I appreciate it! Josh Joshua Megerman SJGames MIB #5273 - OGRE AI Testing Division You can't win; You can't break even; You can't even quit the game. - Layman's translation of the Laws of Thermodynamics j...@honorablemenschen.com
Re: Module naming and a couple other questions
Joshua, 2. It sounds like given the single function and it's relative uniqueness, there's no problem exporting it by default other than not being able to change it later. For the sake of forward compatibility, I'll probably just put it in @EXPORT_OK and require its explicit import. Bearing in mind that I am but one voice, and therefore taking my opinion with the appropriate number of grains of salt, I'll give you my view on the question of to export or not to export. When a module has several functions that I may or may not need, I prefer it to export nothing (e.g. List::Util, List::MoreUtils). When it has exactly one function, and my use of that function is the entire point of my including the module in the first place, I prefer it to export that function (e.g. Date::Format, Date::Parse). Even if it's two functions, if they're very closely related, I'd prefer them to be exported by default (e.g. File::Basename). When a module has exactly one purpose in life, which is to call a function, and it doesn't export it (e.g. Sub::Install), that irks me a little bit, as it forces me to do it myself, and it just seems redundant. As Eric mentions, it's not like I don't know how to stop the export if I really don't want it. Just my perspective, mostly as a user rather than author (but also an author of a few things here and there). -- Buddy
Re: Module naming and a couple other questions
Joshua Megerman writes: I'm a new member of PAUSE, looking to upload my first module. Hi Josh. Thanks for sharing with the Perl community. 1. I have developed a module that provides an XS interface to the WMI library (libasync_wmi_lib.so) that is generated by building the Zenoss WMI software and provides a method of calling the WMI client without forking to use the wmic binary. My initial inclination was to just call the module WMIClient, but I'm starting to think that WMI::Client or some other name would be better. The only 2 modules I currently see on CPAN that provide similar functionality are DBD::WMI and Win32::WMIC, both of which collect and parse the output of `wmic`, which is what my module is designed to avoid. Suggestions on the best way to name it would be greatly appreciated. After reading that, I'm afraid I'm still unclear on what your module does; WMI isn't something I've heard of before. If it's something only of use with Windows, then putting under the Win32:: namespace would be useful, to clearly demark that. Using a suffix ::Client is probably better than Client, if you think a suffix is needed at all. Could an equivalent ::Server module ever be uploaded? Or are all users of WMI effectively clients of it, so ::Client is redundant. 2. Said module currently has 1 function, wmiclient, which I was planning on exporting by default. I see that it's generally recommended not to do that, Make uses import the function explicitly. If you later regret that decision, you could change to exporting it by default. Whereas if you initially export it by default, you're stuck with continuing to do that in later versions, so you don't break code of people relying on it. 3. The module uses several chunks of C code from the WMI package itself, which are distributed under the GPL. My initial license thought was to distribute the .xs file as GPL with the rest of the module package under the same terms as Perl itself, but I don't know if that's a valid licensing model. Can I do that, or do I need to distribute the entire module as GPL (which is OK with me). Is this a problem for distribution via CPAN? Distributing the entire thing as GPL is certainly fine by Cpan, and would definitely comply with the WMI package's terms. You could put a note in the doc asking people to contact you if they would find your module more useful under a different licence. That way you can postpone researching the matter further until somebody does (or possibly never). Cheers Smylers -- New series of TV puzzle show 'Only Connect' (some questions by me) Mondays at 20:30 on BBC4, or iPlayer: http://www.bbc.co.uk/onlyconnect
Re: Module naming and a couple other questions
Hi Josh, # from Joshua Megerman on Friday 14 September 2012: My initial inclination was to just call the module WMIClient, but I'm starting to think that WMI::Client or some other name would be better. The only 2 modules I currently see on CPAN that provide similar functionality are DBD::WMI and Win32::WMIC, I would say Win32::WMIClient if it only run on windows. If this is a wire protocol, you might consider NET:: (sorry it does not google well for me -- but your libasync_wmi_lib.so mention seems to point away from Win32::.) 2. Said module currently has 1 function, wmiclient, which I was planning on exporting by default. I see that it's generally recommended not to do that, In the case of providing one function, it might make more sense to export it by default. One can always disable the import with a `use ... ()`, so nobody is trapped by your decision. But, it is good practice to import functions explicitly or call them with an absolute name because it provides a better answer to how did this function get into my namespace? Can I do that, or do I need to distribute the entire module as GPL... I [am not a lawyer] think you can use copyright law to grant anyone whatever license you like _on the code you wrote_. The GPL will apply to the usage of everything together once they are linked/executed, so your license has to allow for that. ...Is this a problem for distribution via CPAN? No. (I was trying to track down the reference for this and I'm not sure if there's more written on this topic. Basically: as long as your license doesn't prevent it from being freely and widely mirrored and you are not abusing the generosity of the mirrors, it can be on the CPAN.) http://www.cpan.org/misc/cpan-faq.html#Does_CPAN_allow_shareware 4. In order to successfully build this module, you need to have the WMI library installed and specify the location of the WMI source code as a parameter to 'perl Makefile.PL' so it can find the necessary headers (which I'd rather not have to package with the module source). I have specified this in the README and Makefile.PL, but I don't know how to handle that requirement via CPAN. A parameter to Makefile.PL is not going to work well with a CPAN client. If you want to make it really smooth for users, take a look at some of the Alien:: modules -- you could perhaps automate the installation with an Alien::WMI package. Alternatively, you could prompt() in your Makefile.PL. 5. I'm only starting to look into testing now, but one of the requirements for testing this thoroughly will be that information be passed regarding username/password and machine to test against. If you must have a live test, maybe use prompt() -- but be aware that you would be storing that password as plaintext as a side-effect of how the makefile/make process works. You might be able to work something into the test action -- prompt just before running the tests and put the password in an environment variable. (I [am biased] would use Module::Build for that level of customization rather than MakeMaker.) --Eric -- --- http://scratchcomputing.com ---
Module naming and a couple other questions
I originally sent this to modu...@perl.org, but got no responses. I was pointed here and am reposting them with a few tweaks. Any advice greatly appreciated! I'm a new member of PAUSE, looking to upload my first module. I ask for some advice from those who have more experience than I, as I'd like to do this the right way the first time :) 1. I have developed a module that provides an XS interface to the WMI library (libasync_wmi_lib.so) that is generated by building the Zenoss WMI software and provides a method of calling the WMI client without forking to use the wmic binary. My initial inclination was to just call the module WMIClient, but I'm starting to think that WMI::Client or some other name would be better. The only 2 modules I currently see on CPAN that provide similar functionality are DBD::WMI and Win32::WMIC, both of which collect and parse the output of `wmic`, which is what my module is designed to avoid. Suggestions on the best way to name it would be greatly appreciated. 2. Said module currently has 1 function, wmiclient, which I was planning on exporting by default. I see that it's generally recommended not to do that, but it seems that there's little chance of polluting the general namespace, given that the existing WMI modules don't use it nor do they operate that way. At some point I may add an OO interface, but that's not an immediate concern of mine. Do you have any strong objections to the default export? 3. The module uses several chunks of C code from the WMI package itself, which are distributed under the GPL. My initial license thought was to distribute the .xs file as GPL with the rest of the module package under the same terms as Perl itself, but I don't know if that's a valid licensing model. Can I do that, or do I need to distribute the entire module as GPL (which is OK with me). Is this a problem for distribution via CPAN? 4. In order to successfully build this module, you need to have the WMI library installed and specify the location of the WMI source code as a parameter to 'perl Makefile.PL' so it can find the necessary headers (which I'd rather not have to package with the module source). I have specified this in the README and Makefile.PL, but I don't know how to handle that requirement via CPAN. Suggestions/pointers would be appreciated. 5. I'm only starting to look into testing now, but one of the requirements for testing this thoroughly will be that information be passed regarding username/password and machine to test against. Again, I don't know how to handle that requirement via CPAN - if you can point me to a good reference on how to do that, I'd appreciate that as well. Thanks, and I look forward to your response. Josh Joshua Megerman SJGames MIB #5273 - OGRE AI Testing Division You can't win; You can't break even; You can't even quit the game. - Layman's translation of the Laws of Thermodynamics j...@honorablemenschen.com
