Re: My new module Proc::Daemontools
What about: Daemontools::Installinstall/uninstall a server under daemontools (i.e. `ln -s /path-to-startup-dir /service` ...) Daemontools::Configure daemontools server configuration (i.e. `touch /service/qmail/down` ...) Daemontools::Run or Daemontools::Controlyour package Daemontools::whatever ... Hi Tulio, I decided to use the name Proc::Daemontools. I asked it to Russell Nelson(the man hosting the Qmail site) and he agreed with this name. Daemontools is to work with processes, so this name fits well for it. I don´t think these features you suggested would be that practical because people are not installing new daemons every day. When someone wants to install a new service to daemontools, he must read the documentations and make the installation manually. The actions that people do everyday is start/stop the daemons and see their status. This is what I implemented in my module. I can, if requested, implement in my module interfaces for the rest of executables of daemontools, as readproctitle, tai64nlocal, etc. Thank you for yor opinion, bnegrao. -- Tullio Andreatta Finmatica S.p.A.http://www.finmatica.com/ Sede operativa: Via Sorbanella, 30 - I-25100 Brescia ITALY Disclaimer: Please treat this email message in a reasonable way, or we might get angry ( http://www.goldmark.org/jeff/stupid-disclaimers )
Re: Yet another naming question
darren chamberlain wrote: Is this worth putting onto CPAN, it sounds like re-useable functionality, so why not? and, if so, what should it be called? The working name is Parse::MuttStylePatterns, but that's a pretty bad name. should Mail:: be the TLD since it is mail related? Mail::Mutt::Parser is my guess, but I don't know much about mutt.
How to indicate a dependency in my module
Hi all, I´m finishing to write a module, Proc::Daemontools, and it requires that the daemontools package be installed on a machine for it to work. Where must I indicate that this module have a dependency? I already wrote this on the README file. Is there any other place? In my test script, I cause the test to fail if it cannot find a process, 'svscan', running on the machine. Do you think that this can cause all the cpan-testers to fail? Thanks, bnegrao.
Re: How to indicate a dependency in my module
Bruno Negrao wrote: Hi all, I´m finishing to write a module, Proc::Daemontools, and it requires that the daemontools package be installed on a machine for it to work. Where must I indicate that this module have a dependency? I already wrote this on the README file. Is there any other place? I never read READMEs. I read the docs of the module that I see at search.cpan.org In my test script, I cause the test to fail if it cannot find a process, 'svscan', running on the machine. Do you think that this can cause all the cpan-testers to fail? You might look at Spreadsheet::WriteExcel::Simple, which simply skips some tests if it lacks support modules/processes. That way , you don't fail even though you never ran the tests. Thanks, bnegrao.
RE: How to indicate a dependency in my module
: Where must I indicate that this module have a dependency?
You have to indicate it in your Makefile.PL. Here is an example of a
Makefile.PL:
WriteMakefile(
NAME= 'Class::PObject',
VERSION_FROM= 'PObject.pm',
PREREQ_PM = {
'Storable' = 0,
'IO::Dir' = 0,
'Test::More'= 0,
'Log::Agent'= 0,
'File::Spec'= 0,
'File::Path'= 0,
'File::Basename'= 0
},
ABSTRACT= Simple framework for programming persistent objects,
AUTHOR = Sherzod B. Ruzmetov [EMAIL PROTECTED]
);
Note, how it's defining list and min. versions of dependencies
--
Sherzod Ruzmetov
Re: How to indicate a dependency in my module
* Bruno Negrao qmail at engepel.com.br [2003-11-10 17:10]:
I?m finishing to write a module, Proc::Daemontools, and it requires that the
daemontools package be installed on a machine for it to work.
Where must I indicate that this module have a dependency? I already wrote
this on the README file. Is there any other place?
In my test script, I cause the test to fail if it cannot find a process,
'svscan', running on the machine. Do you think that this can cause all the
cpan-testers to fail?
I think the best thing to do in your test would be something like:
my $have_svscan = 0;
if (find_svscan()) {
$have_svscan = 1;
plan tests = 2;
}
else {
plan tests = 1;
}
use_ok(Proc::Daemontools);
ok(Some svscan related test) if $have_svscan;
Where find_svscan looks in the Appropriate Places for svscan, and runs
the tests if it can be found.
(darren)
--
You know the great thing about TV? If something important happens
anywhere at all in the world, no matter what time of the day or night,
you can always change the channel.
-- Jim Ignatowski
pgp0.pgp
Description: PGP signature
Re: Yet another naming question
On Mon, Nov 10, 2003 at 03:06:30PM -0500, darren chamberlain wrote: be the TLD since it is mail related? Mail::Mutt::Parser is my guess, but I don't know much about mutt. Though the idea and syntax originate with mutt (as far as I know, at least), the general idea is not mutt-specific, or even mail-specific. The idea occured to me because I was writing a (non-mail-related) curses-based interface to a database, and needed functionality similar to mutt's Limits. This my initial MuttStylePatterns name. The mutt docs simply call them patterns, but that's much too generic a name for this module, I think. They seem like a kind of regular expression to me. Something under one of these name spaces makes sense to me: Regexp::Mutt Regexp::MuttPatterns Having Patterns in the name might repeat the idea of what RE's are, though. Mark -- . . . . . . . . . . . . . . . . . . . . . . . . . . . Mark StosbergPrincipal Developer [EMAIL PROTECTED] Summersault, LLC 765-939-9301 ext 202 database driven websites . . . . . http://www.summersault.com/ . . . . . . . .
FW: How to indicate a dependency in my module
: In my test script, I cause the test to fail if it
: cannot find a process,
: 'svscan', running on the machine. Do you think that
: this can cause all the
: cpan-testers to fail?
If the whole library has a dependency, and wouldn't function as intended if
they are found missing,
then you have to let Makefile.PL to take care of it (read my prev. message
to this thread).
If dependencies of your test script(s) are different than those of your
actual module, then making them
fail is not a good idea. You have to get them skip all the tests gracefully.
For example, let's skip all the tests if DB_File is not installed.
Remember, that this makes sense
only if DB_File is not a requirement for your actual Module but ONLY for
this particular test:
eval require DB_File;
if ( $@ ) {
print 1..0 #Skipped: DB_File is not available\n;
exit(0);
}
You can also achieve the same effect using Test::More:
use Test::More;
eval require DB_File;
if ( $@ ) {
plan(skip_all=DB_File is not available);
exit(0)
}
If, in our above example, DB_File is a requirement by your actuall module,
say Acme::Module,
then putting checks in your test scripts as we did above would make no
sense! This check had to
put in Makefile.PL:
WriteMakefile (
PREREQ_PM = {
DB_File = 0
}
);
--
Sherzod Ruzmetov
URI: http://author.handalak.com/
Re: How to indicate a dependency in my module
darren chamberlain wrote:
* Randy W. Sims RandyS at ThePierianSpring.org [2003-11-10 15:49]:
Also, as I noted in the AFS thread the other day, this info should be
written in META.yml so that cpan-testers can determine programatically
whether a module should be tested. Info like required non-perl packages
and libraries, whether the build/test/install process is interactive (or
scriptable) or automated, and whether it runs only on certain OSs or
excludes certain OSs.
I like this idea; I must have not been paying close enough attention to
your other message. How could it be done, though? I can see a simple
exression - expected value scheme working for a lot of things (e.g.,
$^0 eq 'MacOS', or eval { getpwuid }; ), but how would things like
AFS be detectible?
(darren)
I'm making this up as I go, but I'm thinking that META.yml would just
contain a list of required packages and possibly the minimum version
required. Initially, that should be enough to flag it for cpan-testers.
Ideally, there would be a module (Module::Build::Configure) that could
try to determine whether those requirements are satisfied for a
particular system. This could be done by a which/where like routine to
search for binaries, looking for config files, analyzing the install log
of package managers like rpm, dpkg, etc.
In addition for larger packages like Apache there could be, for example
an Module::Build::Configure::Apache module that provided other usefull
info about that package like paths and other configuration info that
might be usefull to module authors.
Randy.
