I'm wondering a bit about the worth of adding some older scripts of mine to the cpan, as cpan is pretty much geared to finer-grained function or oo-level reuse instead of coarser pipe/cli level reuse.
At the moment, the victim in question is still a proper standalone script, being wrapped into a tarball setup via module-starter. So if I upload the script to PAUSE, it gets onto cpan.org/scripts, and the tarball is visible with search.cpan.org. Even smoke-testing is active, but rt refuses to see non-official modules.
You can find the victim of this question (aka waitcond) here: http://cpan.org/authors/id/J/JA/JAKOBI/scripts/cliprocesses/
While I have one hard condition that the script must be usable standalone and remain directly usable at the pipe level, turning it into a dual-nature function-library-style module that can still be invoked like a script isn't too difficult. A bit tasteless maybe: That's not a proper refactoring (rather a minor cleanup at best) plus I don't really see many programmatic advantages of 'use' over 'system' for a fairly 'slow' command. OTOH, people knowing cpan could use standard cpan features like CPAN.pm to get/update the script/module, report bugs with rt, etc.
So the first question is: is this worth the effort? Or should perl scripts really leave CPAN and go to say freshmeat as their proper place?
A second harder question: If CPAN is still also somewhat suitable for scripts, what is the preferred name / module hierarchy? Even stuff like App:: looks more like support-for-applications than applications or scripts proper; in addition, it lacks hierarchical structure, thus placing things in App:: feels too much like littering... .
The only example somewhat comparable to my question seems to be App::Ack.
thanx for joining this puzzle with me,
Peter
In reply to cpan and (dual-nature) scripts? by jakobi
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |