Re: Testing for installed headers (and dictionary)
On Thu, May 17, 2007 at 10:49:17PM +0200, A. Pagaltzis wrote:
* Bill Moseley [EMAIL PROTECTED] [2007-05-17 07:10]:
The aspell binary can dump the dictionary names, but someone
might only have libaspell installed and not the binary. I'm not
aware of any other way to detect the dictionary other than
trying to use it.
Put the load attempt within `eval{}` and `plan skip_all` on
failure?
I thought of that, but it kind of defeats the purpose of the tests in
the first place.
End up with the situation where make test fails on systems where the
module probably works fine, vs. where make test passes on systems
where the required dependencies are not installed. ;)
--
Bill Moseley
[EMAIL PROTECTED]
Re: bin:: namespace for utilities on CPAN
# from Chris Dolan # on Thursday 17 May 2007 09:33 pm: LWP::UserAgent has stuff that installs into bin. WWW::Mechanize has stuff that installs into bin. etc etc etc Don't forget Mail::SpamAssassin. That's a popular example of a CPAN- hosted, end-user application. I think it would not be an improvement to rename it Application::Mail::SpamAssassin or bin::Mail::SpamAssassin. I guess I've been horribly misunderstood here? I never said anything about renaming anything. Renaming is not part of the discussion. Big applications should be TLNS. Big applications are not part of the discussion. Distros for little utilities that *want* to live under some directory could live in App with the app frameworks and app builders, but I think it would be a beautiful thing if they chose bin:: instead. --Eric -- If you dig it, it's yours. --An old village poet (via Al Pacino) --- http://scratchcomputing.com ---
Re: bin:: namespace for utilities on CPAN
# from Andy Lester # on Thursday 17 May 2007 08:26 pm: I'm actually having a difficult time getting you all to agree to *recommend* that things which will be installed in a directory named bin/ should have a namespace named bin::? Wow. LWP::UserAgent has stuff that installs into bin. WWW::Mechanize has stuff that installs into bin. etc etc etc Fine. Great. So what? Where do I put hello_world? Where do I put famwatch, reloader, behead, bindiff, dwg_differ, dir_merge, fabsync, and hundreds of other *small* utilities? And. I would be fine with lwp-request being bin::lwp_request. I'm not saying it has to be. I'm also not saying the *distribution* must have the 'bin::' name. bin:: is a good answer to the question of where to put utilities. --Eric -- Moving pianos is dangerous. Moving pianos are dangerous. Buffalo buffalo buffalo buffalo buffalo buffalo buffalo. --- http://scratchcomputing.com ---
Re: pristinance is futile, you will be polluted... Oh well.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 A. Pagaltzis a écrit : So we agree to use bin:: instead, though we can’t enforce that, so then someone releases a non-program in the bin:: namespace and suddenly that TLNS is “dual-use” as well and we have to make up *another* one in order to have it “pristine” and “focused”. Excellent point. I am therefore mostly sold on App::, although I like APP:: too (just for the heck of trying to keep focused even if bound to failure). - -- Tout n'y est pas parfait, mais on y honore certainement les jardiniers Dominique Quatravaux [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBRk1bHfTYH7KfeIIFAQIF9QP/bMuuOdPznIc+Z5u75110uLfNlSpBpkIR F9/An7H9dn75bb1AYkD8npdg07Q+mOErg6v+hibwZjl407AUcgEcOKrhKv5PbVXU xZGboFGfA3y/2riaqXwsAPf+ZrbF2drrlPJCQlfP4DlU2mmlkY4tJbd6mYXzgY2/ xzTyfdYYcjk= =AIPF -END PGP SIGNATURE-
Re: bin:: namespace for utilities on CPAN
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Eric Wilhelm wrote: Where do I put hello_world? Where do I put famwatch, reloader, behead, bindiff, dwg_differ, dir_merge, fabsync, and hundreds of other *small* utilities? Just to put the original discussion back on track: I do *not* envision that PKI app of mine as a small utility. It has several executables, and also crontabs, a configuration file, state persisted on disk, logs that need to be rotated etc. One would best think of NutsPKI as a .deb or .rpm or whatever, only implemented in Perl. bin:: is a good answer to the question of where to put utilities. Well maybe, but how about applications that are not just utilities? If I understand you correctly, utilities is a strict subset of applications. Please elaborate if you disagree. - -- Tout n'y est pas parfait, mais on y honore certainement les jardiniers Dominique Quatravaux [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBRk1Zg/TYH7KfeIIFAQKgfAQAtyfs4odkgcciQGN4bkpnybfNkUQ/N8Rw oWpXu1WYadiAf9CJv4OBg8M0ezbPH9prAwJmjXOjoaZTQnHF9D171xvcCO7NUCc4 OwRbl+Hg8KIdeDk4WTtc+L+8O6G6DhI7WO0fOGi2qZqCUAHB0hMd++WfRKJfcEI1 GmfLLt4mIkQ= =gJEs -END PGP SIGNATURE-
Re: (Create a new ?) namespace for applications on CPAN
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andy Lester wrote: [CPAN] doesn't even come close to being in a strict hierarchy. There are weaker properties of a namespace that are still useful. Not mixing apples oranges is one of them. - -- Tout n'y est pas parfait, mais on y honore certainement les jardiniers Dominique Quatravaux [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBRk1gC/TYH7KfeIIFAQJ8QwP9HHCTtraanDM9fusTPYo8Qee/uZt4dYjS tRjtdIT2ZJ0PrzSfPYWzG+tIwRVa5mA/LNmzKAlOKYy0c15u1Wl7PpyI/5sU2Ee6 rTHoXHPLn4wsm2h0ySXwgb9IFliGrcmOS/ckj+IAHf9Ewqz0IAMqP+GB5AcXzrMi ADvaVwAHTR8= =aimO -END PGP SIGNATURE-
Re: bin:: namespace for utilities on CPAN
# from Dominique Quatravaux # on Friday 18 May 2007 12:45 am: Just to put the original discussion back on track: I do *not* envision that PKI app of mine as a small utility. Yep. Put it in a TLNS. --Eric -- You can't whack a chisel without a big wooden mallet. --- http://scratchcomputing.com ---
Re: (Create a new ?) namespace for applications on CPAN
Andy Lester [EMAIL PROTECTED] writes: I'm trying hard to get people to stop saying script when referring to their Perl programs. I'd prefer that we not use it anywhere at all. Back to 'applications' then. -- Johan
Re: bin:: namespace for utilities on CPAN
Eric Wilhelm [EMAIL PROTECTED] writes: [...] that things which will be installed in a directory named bin/ should have a namespace named bin::? I want to clearly separate a CPAN location and a namespace. Small applications usually do not have (nor need) a private namespace. 'helloworld' is an application that on a *ix system would get installed into /usr/bin or /usr/local/bin, but it would be just 'helloworld', not 'bin::helloworld'. And it's package, if any, would most likely be 'main'. But this does not mean that apps like this cannot be archived in a pseudo-module-toplevel. I think we basically agree that choosing a new pseudo-toplevel would be good to avoid confusion. That rules out App. I think Application would be the best alternative. Complaints that this is too long should be directed to /dev/void. This is the 21st century, my shells and editors all support completion. Some other 'rough' conclusions as I see them emerge from the discussions: - Modules that have accompanying (supporting) tools stay as they are. No need to change LWP, Mail::SpamAssassin etc. A search engine (CPAN indexer?) could be helpful in finding applications that come with modules. - Applications that only use regular CPAN modules could go into the new Application location (not: namespace, see above). So the 'helloworld' kit would become Application-helloworld. The application itself stays 'helloworld'. - Application that have accompanying (supporting) modules currently have no choice other than to put the modules into the perl libraries, making them globally available to any perl application. If this is not desired (and I can think of many situations) an alternative is needed. Another thing is the format of an application kit. I already suggested to use the familiar .tar.gz format, just like module kits. An application kit should contain at least a README, MANIFEST, Makefile.PL and, of course, the application. For the hypothetical 'helloworld' program the kit would be named Application-helloworld-1.00.tar.gz, and contain: Application-helloworld-1.00/README Application-helloworld-1.00/MANIFEST Application-helloworld-1.00/Makefile.PL Application-helloworld-1.00/script/helloworld (I hate to use 'script' but this is what MakeMaker requires.) Where to put private modules? In a system that supports a standard (Linux, Open Desktop, Windows?) the local conventions should be used. But the current kit builders do not support anything like this. An alternative would be to put the modules under the Perl tree, in a pseudo-namespace Application::appname (where appname is the application name). Applications would then have to add a use lib Application::appname; to get at their private modules. In a way, this closes the circle by turning the applications plus supporting modules into modules with an accompanying application ;-). For outsiders, modules that reside under the Application hierarchy should be considered private and not be relied on. -- Johan
Re: (Create a new ?) namespace for applications on CPAN
Andy Lester schreef: Dave Rolsky: ?: What's with all these ad hoc appending of x, like DBIx and RTx? Maybe the componenty parts should be Appx::* ? Well, DBIx is actually something Tim Bunce requested, since he didn't want people adding stuff to the DBI hierarchy. For Mason extensions, we asked people to use MasonX for similar reasons. That's fine. I'm not disagreeing with that. Point is that there's all sorts of stuff out there that doesn't even come close to being in a strict hierarchy. Such a strict hierarchy is not even possible. I wouldn't mind having code-less modules, just containing (future-proof) links to the real ones, something like application::SpamAssassin - Mail::SpamAssassin -- Affijn, Ruud Gewoon is een tijger.
Re: (Create a new ?) namespace for applications on CPAN
On Thu, 17 May 2007, Andy Lester wrote: On May 17, 2007, at 12:06 PM, Andreas J. Koenig wrote: One of the oldest ideas for namespace decisions was that when a family of modules constitutes something you can perceive as a framework, then any top level namespace is ok. It makes no sense when everybody just grabs a toplevel namespace with a cute name but when you come with a bag of modules, you deserve one. The whole idea of levels of namespace has pretty much been outdated anyway. Why is Nike::Foo any better or worse than App::Nike::Foo? Nobody actually uses this hierarchy. There's not some outline. We don't traverse a strict tree. Erm... yes we do. Yeah, there's no tree-browsing capability on CPAN. I wish there was. Right now I have to make do by entering things like Math:: in the CPAN search box. It's clunky, but it is all I've got, since the ridiculous and useless modlist seems to be treated as an alternative to tree-like searching. Does it matter that WWW::Mechanize isn't LWP::Mechanize? Shouldn't similar things be named in the same TLNS? Why isn't RT::* App::RT::*? Or WWW::RT::*? Because there's no official tree structure. Straw man argument, we already know that. That doesn't mean that we don't try to give at least a semblance of order. That there are multiple trees doesn't changed the fact that there are trees. -john
Re: bin:: namespace for utilities on CPAN
# from Johan Vromans # on Friday 18 May 2007 02:35 am: Application-helloworld-1.00/README Application-helloworld-1.00/MANIFEST Application-helloworld-1.00/Makefile.PL Application-helloworld-1.00/script/helloworld (I hate to use 'script' but this is what MakeMaker requires.) Application-helloworld-1.00/README Application-helloworld-1.00/MANIFEST Application-helloworld-1.00/META.yml Application-helloworld-1.00/Build.PL Application-helloworld-1.00/bin/helloworld --Eric -- Anyone who has the power to make you believe absurdities has the power to make you commit injustices. --Voltaire --- http://scratchcomputing.com ---
Re: bin:: namespace for utilities on CPAN
# from Johan Vromans
# on Friday 18 May 2007 02:35 am:
but it would be just
'helloworld', not 'bin::helloworld'. And it's package, if any, would
most likely be 'main'.
I've found that it is much easier to test and refactor programs which
are not written against the left margin in package main. Here's an
example of the skeleton which I currently use.
The bit in package main decides if we're being require()d or not (though
PAR and PerlWrapper currently both break this without a bit of code
which is omitted for simplicity.)
The package bin::helloworld has a version number, documentation, etc.
Everything it needs to be a module. Again, this is all about
refactorability (though there's some readability at play too.)
#!/usr/bin/perl
use warnings;
use strict;
package bin::helloworld;
our $VERSION = v0.0.1;
=head1 NAME
bin::helloworld - says hi
=cut
=head1 Functions
=cut
sub main {
my (@args) = @_;
my $who = who();
print hello , $who, \n;
}
=head2 set_who
Sets the $WHO for hello.
set_who('universe');
=cut
my $WHO = 'world';
sub set_who {
($WHO) = @_;
}
sub who {
$WHO;
}
package main;
if($0 eq __FILE__) {
bin::helloworld::main(@ARGV);
}
# vi:ts=2:sw=2:et:sta
my $package = 'bin::helloworld';
The distribution would be like:
bin-helloworld/README
bin-helloworld/MANIFEST
bin-helloworld/META.yml
bin-helloworld/Build.PL
bin-helloworld/bin/helloworld
bin-helloworld/t/00-load_bin_helloworld.t
I hope that sheds some light on my motivation.
Also, consider that this could go in the @INC tree under bin/ and be
symlinked from there to /usr/bin/ or whatever. And yes, we're
currently lacking installer support for that. (For qdos, we're missing
symlinks, but the only executables have eXe or BaT names, so follow
Vanilla's C:/Perl/bin/foo.bat scheme, where the bat file now does perl
-e 'require(bin/helloworld); bin::helloworld::main(@ARGV)' or
thereabouts.)
It also enables the test-in-situ (retest?) scheme, makes
bin::helloworld-VERSION work, and maybe a few other things.
Could most of that happen with qr/[Aa]pp(?:lication)?/ or whatever?
Sure. Would it have the same parallel to bin/? No.
--Eric
--
The reasonable man adapts himself to the world; the unreasonable man
persists in trying to adapt the world to himself. Therefore all progress
depends on the unreasonable man.
--George Bernard Shaw
---
http://scratchcomputing.com
---
Module Proposal: Number::Collection
Hello, I recently created a module for encoding and decoding numerical arrays to strings, in the form of 1,4,10-29, with duplicates being supported. It works by optionally exporting a selection of functions including encode_array, decode_array, validate_encoded_array, add_encoded_arrays, subtract_encoded_arrays. Probably will add another function to remove duplicates and allow greater flexibility with the format of the string in the future. Tempted to possibly add more set logic - though don't want to make it overlap Set::Scalar too much. It's main uses would be for display and user entry. For instance in a web application it could be used to specify a collection of ID numbers in a shortened form, rather than having to select them all individually. I was thinking of calling it Number::Collection - but wasn't sure if that's appropriate or not. I've already written the bulk of the module and a series of tests and POD for it, which I can show if need be. Best wishes -- K. J. Cheetham MPhys (hons) AMInstP Software Developer Shadowcat Systems Ltd. http://www.shadowcatsystems.co.uk/
Re: Module Proposal: Number::Collection
On 18 May 2007, at 16:21, K. J. Cheetham wrote: I've already written the bulk of the module and a series of tests and POD for it, which I can show if need be. How does it intersect with http://search.cpan.org/dist/Set-IntSpan/ and http://search.cpan.org/dist/Set-IntSpan-Fast/ ? -- Andy Armstrong, hexten.net
Re: Module Proposal: Number::Collection
# from K. J. Cheetham # on Friday 18 May 2007 08:21 am: I recently created a module for encoding and decoding numerical arrays to strings, in the form of 1,4,10-29, with duplicates being supported. Maybe Set::Stringify, Set::AsStrings, Set::Encode, or Set::Serialize? Number::Collection doesn't imply anything about stringification. Tempted to possibly add more set logic - though don't want to make it overlap Set::Scalar too much. Make them interoperable? --Eric -- As an old bass player friend of mine used to say: throw money, don't clap. --Tony Parisi --- http://scratchcomputing.com ---
Re: bin:: namespace for utilities on CPAN
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Eric Wilhelm wrote: I've found that it is much easier to test and refactor programs which are not written against the left margin in package main. Sure. svk is an especially striking example of this discipline. Could most of that happen with qr/[Aa]pp(?:lication)?/ or whatever? Sure. However good this practice is, it is a matter of coding style and therefore taste, and CPAN authors should be free to decline it. Enforcing best practices through namespaces is Oh So Not Perlish; more like Java! - -- Tout n'y est pas parfait, mais on y honore certainement les jardiniers Dominique Quatravaux [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBRk39N/TYH7KfeIIFAQJTZQP9Fpha5ueKcjmLHq/QKBGDD0I3ytlK1lPM ZsM/1+yzuDG1gI1blwocfh7Ydv/fVPEWRFjYQXYEp9v8qxRam1aV12cq8OeckARs nNdHEq7H5w7v/JEfWn5010uJBHj/Oeb9DFXLc4x4SjMyWu9KIRxKcTXa4YZ0lysK As6VG3+MnkQ= =u0F8 -END PGP SIGNATURE-
Re: bin:: namespace for utilities on CPAN
Eric Wilhelm [EMAIL PROTECTED] writes: I've found that it is much easier to test and refactor programs which are not written against the left margin in package main. You are free to do it like this. Here's an example of the skeleton which I currently use. Yes, I have several of those as well ;-). Hoewever, it should not be a requirement. We could make it a recommendation. The distribution would be like: bin-helloworld/README bin-helloworld/MANIFEST bin-helloworld/META.yml bin-helloworld/Build.PL bin-helloworld/bin/helloworld bin-helloworld/t/00-load_bin_helloworld.t Looks nice, although I'd plea for 'application' instead of 'bin'. This is something new, and the association for 'bin' is not neccessarily trivial for everyone. So, one of the first things we'd need is a Application::Starter module (program?) to set up the basic structure. And yes, we're currently lacking installer support for that. You seem to be rather fluid with Module::Build. Would it be an option to have Application::Starter put a Module::Build derived class in the generated structure to deal with that? Could most of that happen with qr/[Aa]pp(?:lication)?/ or whatever? Sure. Would it have the same parallel to bin/? No. As indicated, I'm not sure everyone feels the bin parallel like you and me. So I still opt for Application. -- Johan
Re: bin:: namespace for utilities on CPAN
# from Dominique Quatravaux # on Friday 18 May 2007 12:23 pm: Could most of that happen with qr/[Aa]pp(?:lication)?/ or whatever? Sure. However good this practice is, it is a matter of coding style and therefore taste, and CPAN authors should be free to decline it. Enforcing best practices through namespaces is Oh So Not Perlish; more like Java! Nothing I said was about enforcement. Nobody has a whacking stick long enough to even reach most of the authors from any given geographic location. I would have to be more than crazy to think anything could be enforced. But I am not more than crazy. I think bin:: would *support* the practice. I don't think recommending it would get in anyone's way either. I even think it would also be fine to apply this convention to programs nested in other distributions. As for taste: Most people will agree on something tasting very bad and many people will agree on something tasting very good. So, we should never just dismiss something as a matter of taste. --Eric -- If you only know how to use a hammer, every problem begins to look like a nail. --Richard B. Johnson --- http://scratchcomputing.com ---
Re: module/program publication workflow (was: bin:: namespace for utilities on CPAN)
# from Johan Vromans # on Friday 18 May 2007 12:46 pm: Hoewever, it should not be a requirement. We could make it a recommendation. Please stop saying anything about requirements! I never mentioned requirement, enforcement, etc. So, one of the first things we'd need is a Application::Starter module (program?) to set up the basic structure. I'm currently using a very hacked-up Module::Starter for modules, but the config-via-subclassing scheme can be painful and has to be debugged as soon as it becomes non-trivial. It could be made to work for scripts, but I think would involve deleting some .pm files after generation. So I would like to take a step back and look comprehensively at the whole boiler-plate, test, version control, publish issue. This is what I'm calling The Comprehensive Perl Development Kit. The current code is only a rough-in and pile of notes, but I'm working on it as part of the three-platform binary + source release mechanism of dotReader, so... http://scratchcomputing.com/svn/CPDK/trunk/ See also: ShipIt and maybe a few others. This is fairly nascent, but the idea is to somehow support user+project config files and mixins or traits rather than subclasses as a means of customization (with the utopian idea that cooperating tools and components could be built by multiple authors.) I have a dream that I'll oneday be able to hit a big button to bring CPAN releases up-to-date with my svn but I don't claim to exactly have the answer for how it works. As for the script-as-module skeleton, this is one of those works-for-me things which could fairly easily be brought into the CPDK scheme. http://scratchcomputing.com/svn/misc/trunk/code/perl/bin/new_tool And yes, we're currently lacking installer support for that. You seem to be rather fluid with Module::Build. Would it be an option to have Application::Starter put a Module::Build derived class in the generated structure to deal with that? Sure. Or a dependency on a plugin, or just builtin support in Module::Build. For now, I think we can just create a Build.PL that is able to get the version number and author from the script and have a pretty descent script-only distro. Of course, I'll have too look into what happens in the absence of a lib dir. But that's enough of reciting my todo list for one day. I'll have to see where the tuits fall. --Eric -- If the above message is encrypted and you have lost your pgp key, please send a self-addressed, stamped lead box to the address below. --- http://scratchcomputing.com ---
Re: bin:: namespace for utilities on CPAN
On May 18, 2007, at 3:15 AM, Dominique Quatravaux wrote: Chris Dolan wrote: Don't forget Mail::SpamAssassin. That's a popular example of a CPAN-hosted, end-user application. I think it would not be an improvement to rename it Application::Mail::SpamAssassin or bin::Mail::SpamAssassin. Does this mean you are advising Crypt::NutsPKI in my situation over App::NutsPKI? Maybe, maybe not. I advocate for the name that would get the most hits in a search by a user looking for a module like yours. Given my limited understanding of what you app will do, I *think* I prefer App::NutsPKI over Crypt:: because the latter sounds more like a library than an app. That said, the Nuts part of the name means nothing to me... Chris -- Chris Dolan, Equilibrious LLC, http://equilibrious.net/ Public key: http://chrisdolan.net/public.key vCard: http://chrisdolan.net/ChrisDolan.vcf
Re: bin:: namespace for utilities on CPAN
# from Chris Dolan # on Friday 18 May 2007 07:52 pm: I *think* I prefer App::NutsPKI over Crypt:: because the latter sounds more like a library than an app. I think this is big enough to be just NutsPKI. If anything, it would probably be better under Crypt:: than App::, but I do agree with Chris about that sounding like a library. If there is a library interface e.g. a Crypt::NutsPKI-new(), then sure. --Eric -- But as soon as you hear the Doppler shift dropping in pitch, you know that they're probably going to miss your house, because if they were on a collision course with your house, the pitch would stay the same until impact. As I said, that's one's subtle. --Larry Wall --- http://scratchcomputing.com ---
