At 9:33 PM -0800 2/9/03, [EMAIL PROTECTED] wrote:
(detail snipped)Steve Linberg wrote:I thought this might be a good time to learn how to do a proper packaging of the modules so they could be installed via the standard "perl Makefile.PL && make && make test && make install", and I've begun to find documentation about how to do that.h2xs -AX -n MyModule::SubModule
Thanks for the info, Greg. I started doing that this weekend, but I somehow missed the "make dist" bit! That's a bit easier than what I was doing.
Really, they're just miscellaneous functions that I find useful on mod_perl sites I do: some are related to common date formats and parsing that I use, for example; some related to web-oriented list management; others for forms processing and so forth.As for namespace selection, you can look for similar stuff on CPAN to see if there's a good parent namespace under which to place your various packages. It might be there really isn't much in common with them other than they are useful tools for developers to use to write their programs, in which case Devel:: would work.
The difficulty is that there are plenty of modules on CPAN that do a melange of these things, but I wrote my code before I was aware of them, and I'm pretty used to it... they have some things, for example, that the better-established modules don't, and I'm just more familiar with them. What they have in common is that I use them together a lot. That's about it.
If I tried to organize them by category, they'd be scattered all over the place, and I'm not sure that's a good thing, especially in areas that already have zillions of modules (Time::, HTML::, Text::, and so forth).
Personally, I despise the author's name being wrapped into the package name. I had to work with 15 year old code that contained various three-letter-acronym files. I quickly learned that the TLA's were programmer initials. And the initials were completely useless to me, because B.K.A. worked at the branch office in California, and he quit 8 years ago. And it didnt tell me anything about what his code did.
I hear that. I guess I'm still not sure what to do. Hrm.
Advice appreciated. In my case, I'm a one-man shop (mostly), so I hereby grant myself permission. :) I'm also not a corporation (yet), just a DBA. I suppose I could do SGT_DBA::Foo.pm, but then if I ever BECOME a corporation then that won't be right anymore.on a side note: before you put it under a MyCorp:: parent namespace, is your company cool with you releasing code to CPAN? or are you just looking for a namespace for proprietary code so it won't conflict with anything a client might get from CPAN? If it's proprietary, then MyCorp:: might be the best approach.
What a calamity!
Since I'm not rushing this stuff to CPAN (I don't think much of it is good enough for release to the world in its present state, but as I clean it up it might be), I have some time to think about it... and since I'm deploying mostly only on my own hardware, making changes down the road is easy enough. It almost makes me wish there was a namespace on CPAN dedicated to this kind of grouping, like "BIZ::" or "CORP::" or "PRIV::" or something "official" like that.
- Steve
--
Steve Linberg, Chief Goblin
Silicon Goblin Technologies
http://silicongoblin.com
Be kind. Remember, everyone you meet is fighting a hard battle.
_______________________________________________
Boston-pm mailing list
[EMAIL PROTECTED]
http://mail.pm.org/mailman/listinfo/boston-pm
