Re: CPAN and META.yml: no_index dir vs directory
Andreas J. Koenig wrote: On Wed, 5 Jul 2006 21:39:06 -0500, Ken Williams [EMAIL PROTECTED] said: On Jul 5, 2006, at 7:47 PM, David Golden wrote: Some potential options: (a) Add directory as a synonym to the spec and add dir as something that CPAN sites recognize. (b) Change the spec to directory -- if CPAN sites are the only real user of META.yml no_index, then the pain should be minimal. (c) Change CPAN sites to follow the spec, despite breaking many distributions' current indexing. Randy Sims keeps some statistics on the META.yml files that exist on CPAN, perhaps he could tell us the relative frequencies of 'dir' vs. 'directory' in the wild? The page is there, http://thepierianspring.org/perl/meta/, but does not provide direct statistics so I made up my own. Now it does. ;) no_index/dir 13 no_index/directory 1397 private/directory40 My numbers are a bit different since I count only the most recent version of each distro rather than every occurrence on CPAN. Hmm, it looks like there is a strong correspondence between distros using 'directory' and distros produced by Module::Install. There goes Adam, breaking rules and rebelling against established conventions. Hehe. Just kidding. I think I like 'directory' better myself anyway. Randy.
Re: Testing an FTP module
Scott W Gifford wrote: I just uploaded to CPAN some FTP-related modules (Net::FTP::AutoReconnect and Net::FTP::RetrHandle). In one of the unit tests, I connect to ftp.cpan.org and retreive MIRRORED.BY to make sure everything works OK. Just in the last little bit, though, I've noticed that a connection to ftp.cpan.org is timing out. So my questions are: * Is ftp.cpan.org a reliable way to access CPAN? Is there a more reliable way, besides looking and MIRRORED.BY? * Is testing by connecting to CPAN an appropriate thing to do? I would guess not. Certainly not without asking permission. * If not, what's a better way to do unit tests for a network protocol? Write or bundle a tiny server, or query the user to provide an ftp server? Thanks for any thoughts! ---ScottG. Regards, Randy.
Re: Games::RoundRobin::Schedule or Games::Schedule::RoundRobin
Dr Bean wrote: On Mon, 30 Jan 2006, A. Pagaltzis wrote: * Dr Bean [EMAIL PROTECTED] [2006-01-30 13:30]: Scoring, however, is perhaps another area that could have its own module. However, I think it’s not unnatural in the least to have a Games::RoundRobin for scheduling and Games::RoundRobin::Scoring for scoring. Wouldn't that mean I would be claiming a name that a more ambitious module had more right to use? libtour models a lot more of the administration of a tournament, eg it allows for preliminary rounds and finals, managed programmatically. If anything, I’d be inclined to suggest Games::Tournament::RoundRobin instead. You are referring to a very specific kind of scheduling/scoring, a point which the ::Schedule/::Scoring namespaces don’t really capture, irrespective of the level at which they appear. I never really thought about that. I guess the reason I didn't include 'Tournament' is because I wanted to keep the length of the name down to 3 levels. Perhaps I should call it Tournament::RoundRobin::Schedule. Most of the content of the modules in the Games hierarchy have little to do with the content of this module. Generally, names are from generic to specific, so it'd be Schedule::RoundRobin -or- Algorithm::Schedule::RoundRobin But that name can apply to many things, such as process scheduling[1]. If the algorithm is not generic enough to apply to anything, it needs more context (when naming: context on left, detail on right): Sports::Schedule::RoundRobin or similar... 1. http://en.wikipedia.org/wiki/Scheduling Scheduling can include many things, eg dates and venues, but timetable scheduling seems to be the name for software that makes timetables, a similar sort of problem. -- Dr Bean, Taiwan
Re: Looking for a name for a module
David Golden wrote: José Castro wrote: - you give it a set of texts (usually two, but can be more) - without knowing the language of each text, the module tells you how likely it is that those texts are translations of each other It would probably be something in the Text of Lingua namespace, and it would probably include something like Translations or Parallel. I tend to think of language things in Lingua and text processing in Text, so I'd lean towards Lingua. After that, my first thought was the unwieldy: Lingua::Translation::Identify or Lingua::Translation::Compare I'm not sure if it makes sense to shorten it to the existing Lingua::Translate namespace for consistency sake: Lingua::Translate::Identify Lingua::Translate::Compare As I look at this, I lean slightly towards compare since it definitely compares, but doesn't necessarily identify. Often, 'similar' is used in this context, algorithms that compare or rate things for equivelance. Lingua::Text::Similar Lingua::Translation::Similar Regards, Randy.
Re: Module::Build Question: Installing Templates in a user-specifiable directory
Shlomi Fish wrote:
Hi all!
Hi Shlomi,
Sorry for the delayed response.
I've written a module using Module::Build and CGI::Application. I'm using
several Template Toolkit templates all placed in one directory. (placed
inside the module tree under ./templates/). I'm setting this template
directory to the default TT search path using $self-tt_include_path().
Now, I'd like to install this module in the path system eventually. The
templates directory should be installed in someplace like
/usr/share/shlomif/myapp/templates, but one that can be over-rided by the
installer, or calculated from various parameters like $DESTDIR, etc.
There are a few ways to do this depending on how much flexibility you
want. Some of this is detailed in Module::Build::Cookbook. The simplest
method requires enumerating your custom files:
use strict;
use warnings;
# probe for directory for template files
sub tt_inc {
# detect install path
return '/var/tmp/templates';
}
use Module::Build;
my $builder = Module::Build-new(
module_name = 'Foo',
license = 'perl',
install_path = {
templates = tt_inc(),
},
templates_files = {
'templates/Foo.tt' = 'templates/Foo.tt',
},
);
$builder-add_build_element( 'templates' );
$builder-create_build_script;
__END__
The method add_build_element() tells MB about a type of file it should
know about. The 'install_path' entry in the constructor gives a default
location where files of that type will be installed on the users system.
The ${type}_files entry (i.e. the templates_files entry in the
example above) provides a map from the files location in the build
directory to it's relative install path.
A slightly more complex version that doesn't require enumerating files
might look like:
use strict;
use warnings;
use Module::Build 0.2611;
my $build_class = Module::Build-subclass( code = '---' );
sub find_templates_files {
my $self = shift;
my %files;
use File::Find;
find( sub {
return if -d;
$files{$File::Find::name} = $File::Find::name;
}, 'templates' );
return \%files;
}
---
# probe for directory for template files
sub tt_inc {
# detect install path
return '/var/tmp/templates';
}
my $builder = $build_class-new(
module_name = 'Foo',
license = 'perl',
install_path = {
templates = tt_inc(),
},
);
$builder-add_build_element( 'templates' );
$builder-create_build_script;
__END__
In this example the ${type}_files argument to the constructor is
replaced by a find_${type}_files() method in a custom subclass.
Taking it one more step, you can provide a method,
process_${type}_files() in place of find_${type}_files() which
allows you more flexibility, for example if you wanted to create the
template files on the fly:
use strict;
use warnings;
use Module::Build 0.2611;
my $build_class = Module::Build-subclass( code = '---' );
use File::Path;
use File::Spec;
sub process_templates_files {
my $self = shift;
my $tt_dir = File::Spec-catdir( $self-blib, 'templates' );
mkpath( $tt_dir );
my $tt_file = File::Spec-catfile( $tt_dir, 'foo.tt' );
open( my $fh, $tt_file ) or die $!;
print $fh 'baz';
close( $fh );
}
---
# probe for directory for template files
sub tt_inc {
# detect install path
return '/var/tmp/templates';
}
my $builder = $build_class-new(
module_name = 'Foo',
license = 'perl',
install_path = {
templates = tt_inc(),
},
);
$builder-add_build_element( 'templates' );
$builder-create_build_script;
__END__
In all the examples above the user can override the default install path:
perl Build install --install_path templates=/path/to/templates
I'd also like to have a generate .pm file that reads something like that:
package Shlomif::MyApp::DefaultConfig;
sub get_templates_dir
{
return /usr/share/shlomif/myapp/templates;
}
1;
Or a different value in case it was installed somewhere else. This is so web
scripts that uses this CGI Application will know where to find its templates.
Hmm, MB has some support for creating a custom configuration file. I'm
not sure if the current release is flexible enough to allow what you
want; I haven't really played much with that yet myself. The other
option would be to define a subclass similar to the examples above that
overrides the 'ACTION_code()' method. Call the super class method at the
top, then write out your own module into the blib directory.
Regards,
Randy.
Re: Checking for boilerplate
Ricardo SIGNES wrote:
* Andy Lester [EMAIL PROTECTED] [2005-08-22T15:07:47]
RJBS and I are going to put some tests into Module::Starter to check for
boilerplate. Watch for it tomorrow, maybe tonight.
Just a little while ago I uploaded 1.41_01, which adds:
* t/boilerplate.t
* some bug fixes
* simple email address obfuscation
* hook for new, improved plugin architecture
The boilerplate check is simple, but should catch the main offenses --
as long as people test before uploading.
I've played with the new version a bit on Debian Linux and Windows. Just
a few very very minor comments:
1) I'm not a big fan of email obfuscation, though I might be in the
minority. Most forms are just as easy to parse as a regular email
address. And obfuscation feels too much like surrendering. Just my
opinion. But an option might be nice if not too much trouble.
2) I like the boilerplate tests in M::S. It feels like an appropriate
place since M::S puts it in, it might as well create tests to make sure
it gets removed. However, I use M::S a lot for creating quick test
distros, and that sometimes makes the failing tests annoying. But my
usage is probably unusual in this reguard. It'd be nice if there were an
option to diable it, but I can easily create a wrapper that fixes it
for my purposes.
3) I goofed on the commandline and typod `module-starter --module Foo
--mb --version` and scratched my head for a while looking for the 'Foo'
directory. Should have type 'verbose'. Maybe 'version' could be an
exclusive option, generating an error in the presence of other options?
Or I should learn to type better.
4) Since M::S can generate distros with a Build.PL it might be nice if
it also included one. ;)
# vi:et:sw=4 ts=4
use strict;
use warnings;
use 5.6.1;
use Module::Build;
my $build = Module::Build-new(
module_name = 'Module::Starter',
license = 'perl',
dist_author = [
'Andy Lester [EMAIL PROTECTED]',
'Ricardo SIGNES [EMAIL PROTECTED]',
],
script_files = [ 'bin/module-starter' ],
requires = {
'Test::More'= 0,
'ExtUtils::Command' = 0,
'File::Spec'= 0,
'Getopt::Long' = 0,
'Pod::Usage'= 0,
},
);
$build-create_build_script;
__END__
*NOTE you must also add to Makefile.PL
WriteMakefile(
...
PL_FILES= {}, # don't auto expand 'Build.PL'
);
And, optionally, do a `perl Build.PL` `perl Build distmeta` to update
your META.yml file.
Re: Checking for boilerplate
Wasn't paying attention when I copied prereqs from Makefile.PL
Randy W. Sims wrote:
4) Since M::S can generate distros with a Build.PL it might be nice if
it also included one. ;)
# vi:et:sw=4 ts=4
use strict;
use warnings;
use 5.6.1;
use Module::Build;
my $build = Module::Build-new(
module_name = 'Module::Starter',
license = 'perl',
dist_author = [
'Andy Lester [EMAIL PROTECTED]',
'Ricardo SIGNES [EMAIL PROTECTED]',
],
script_files = [ 'bin/module-starter' ],
build_requires = {
'Test::More'= 0,
},
requires = {
'ExtUtils::Command' = 0,
'File::Spec'= 0,
'Getopt::Long' = 0,
'Pod::Usage'= 0,
},
);
$build-create_build_script;
__END__
Re: Perl6 goes where?
Ken Williams wrote: On Jul 28, 2005, at 6:26 PM, Randy W. Sims wrote: As far as distinguishing, there a lot of talk in the past in the context of Apache2 about adding a field (generation) which serves basically the same purpose - It distinguishes between multiple code bases intended for different targets. Personally I really don't like the idea of the generation field. I think it's too strict a mechanism for a nebulous notion. Doh! I guess that was kind of a dumb idea since we already have requires: perl: 6.0 in META.yml which works perfectly well for that.
Re: Perl6 goes where?
Ovid wrote: --- Ken Williams [EMAIL PROTECTED] wrote: On Jul 28, 2005, at 6:26 PM, Randy W. Sims wrote: That's true. All the smarts could be centralized in the indexer. But then there's the problem of making sure when someone's browsing CPAN manually (on a regular mirror or on search.cpan.org or wherever) that they don't accidentally download perl6 modules when they meant to download perl5 modules. CPAN(PLUS)? may use only the index files, but people's brains don't. Because we still put require 6 in Build.PL and their perl Build.PL chokes and they see pretty quickly what's going on (we hope.) Then at least there's a chance of them figuring out how to resolve the problem. So far, putting stuff in the indexer is the best idea I've heard. Hmm, this could probably be fixed easily also. Either by using a Apache handler for directory listings (?not too familiar with web development, but isn't that what is used when a directory listing is requested?) or by having PAUSE generate/update an index file for each module/author directory at the time of submission. If it's a P6 distribution, the listing could display a special icon. Not sure how this would affect performance of the server... Might be a good idea to run this whole scenario by Andreas Koenig, and then by the folks over on the perl6.language list. There may be valid reasons for wanting a seperate server, but I can't think of anything off-hand. Randy.
Re: Request for Comments - Tree::Node module?
imacat wrote: On Wed, 29 Jun 2005 09:42:32 -0500 (CDT) Randy Kobes [EMAIL PROTECTED] wrote: requests for making up ppm packages. Alternatively, there are free C compilers for Windows, including Visual C++ 7, for people willing to build their own perl. Could you tell me where to obtain it? Thank you. MinGW GCC http://mingw.org/download.shtml Borland C http://www.borland.com/downloads/download_cbuilder.html Microsoft C http://msdn.microsoft.com/visualc/vctoolkit2003/ Note: you must compile Perl and all modules with the same compiler (or C runtime library).
Re: Failing Reports due to 3rd Party Software...
Barbie wrote: From: Jos I. Boumans [EMAIL PROTECTED] Why the need for such an immensive framework? to be able to probe for any type of file/function on any type of OS is not going to be trivial. To look for every possibility yes that would be emmense. However, I wasn't expecting to go that far. There are a few cross-platform ways of looking for libraries and apps, as has been indicated by have_library() and the like. By refering to Module::Install, I meant the check module would be part of the distribution, and be called within Makefile.PL/Build.PL before calls to the appropriate build mechanism. Although a long way from being done, there is a spec for a small scripting language[1] that has been discussed and mostly agreed on, at least experimentally, for describing requirements on modules, external libs, header files, programs, OS, perl features (threading, large file), etc. The plan is to include it as part of the META.yml spec and to write a module[2] that reads, writes, and validates the requirements described in the META.yml file. With a way to describe all requirements in META.yml and a module to validate it it would be possible for CPANPLUS to grab the META.yml, validate it, and then decide whether to download the actual module. ??? The tentative plan is to put the generic lib, include, program, compiler detection code in the Probe::* namespace so other modules like ExtUtils::CBuilder can also access the functionality. This is all tentative and apparently a good ways off; mostly because I'm very slow. Randy. 1. http://svn.versiondude.net/randys/dEx/trunk/lib/dEx.pm 2. http://svn.versiondude.net/randys/CPAN-Metadata/trunk/
Probing requirements (was: Re: Some ideas)
Robert Rothenberg wrote:
I'm all for something like this, though I prefer requires_libraries
instead. (Listing libraries distinct from applications is a grey area,
so best to put them under one term.)
Come to think of it, why not recommends_libraries too?
What is needed is some standard set of library and application names.
Implementing platform-independent logic to find these libraries is
another matter.
Here's an idea. A module namespace called Config::Libraries, such as
Config::Libraries-info('libgd')
which returns a hash of relevant information about the library. Some of
the hash keys would be standardized, such as one to return a path to
where the library or application is installed, another to return the
version. (It would return undef if the library was not installed.)
This information would be read from an adequate text configuration file
format (YAML or IniFile).
There should be another interface to update the config file easily,
along with a command-line script to do this.
Library installation utilities can use this script, or users can use it
to manually update the config as needed.
The module would have some messy installation procedure that sets up an
initial script. Ideally it should have Platform-specific parts inside
generic wrapper methods. There might be a separate installation file
for each application that uses these methods to configure itself: this
way adding a new library to the utility is a matter of adding script.
Pseudo-library names could be given to special capabilities that some
systems do not have.
The downside is controlling the library namespace. Whoever controls the
Config::Libraries module would have the de facto control, which is
probably good enough for the time being.
That said, who has time to work on such a project? I've got my hands
full already.
Eventually there will likely be a series of modules in Probe::* to deal
with this sort of stuff. If no one else is interested I guess I'll
eventually get around to it. The functionality is needed for
Module::Build, specifically for either the proposed fields to the META
spec or dEx[1] which is intended as an alternative solution to many of
the proposed fields in the META spec.
There will be things like:
Probe::OS - Gather info on the operating system
Probe::Libs
Probe::Progs
Probe::FileSys - maybe incorporate ideas Schwern posted on p5p recently,
detecting sensitivity, preservability of case, etc
Probe::Locations - where to install parts of apps, config files, data files
Probe::Apache
etc.
(IIUC, this namespace was once proposed for this use, but noone has
developed it.)
At least this is what I'm thinking at the moment. It's subject to
change. And this is a long way into the future. Lots of stuff to be done
first.
1.
https://svn.versiondude.net/wsvn/randys/wsvn/dEx/trunk/lib/dEx.pm?op=file
Re: RFC: some thoughts about daemons and related modules
Baltasar Cevc wrote: One possibility would certainly be to generalize Net::Daemon to something like a App::Daemon or Proc::Daemon (the latter exists, but has only a limited functionality, concentrates just on the real daemonizing and does not take care about PID etc.) or something in that direction. Have you checked with the author of that module to see if he/she is interested in extending the module? Perhaps a collaboration? Or maybe you can inherit from it, and extend it yourself? Randy.
Re: better SEE ALSO sections
Andrew Savige wrote: Shamless plug: since you are a relative newbie, you might find this article: http://www.perlmonks.org/?node_id=418891 an interesting read, especially the section Testability and Test Suite. Also check out the perl-qa mailing list for all kinds of testing quality issues. http://lists.perl.org/showlist.cgi?name=perl-qa
Re: Name for GStreamer bindings
Torsten Schoenfeld wrote: On Fri, 2005-02-25 at 09:43 +0100, A. Pagaltzis wrote: use constant Gst='Multimedia::Gstreamer'; Gst-new(); I just realized that this won't work. I don't just need Gst to be an alias for Media::GStreamer, I need Gst::* to be an alias for Media::GStreamer::*. That also seems to rule out the aliased.pm approach. Why? Sure, you need many constants, not just one, but does that matter? No, not really. It seems a bit cumbersome, but I guess it would work. Something that doesn't seem to have come up in debate here is that the distribution and main module namespace need not dictate the package names for classes. You could well stick everything in Gst:: even though your modules are called Media::GStreamer(::.*)?. This sounds very evil, but might actually work! This would solve the problem in a pretty elegant way: No top-level CPAN pollution, but a usable namespace. Is this a bad idea even if it's clearly documentent? That's the question. What do others think? I'd consider it a very bad practice. Imagine if many authors started doing the same. There could be unpredictable collisions all over the place. It defeats the CPAN scheme for ensuring unique namespaces. I still don't see the problem of using a proper namespace. Arguments of length are not compelling. What's wrong with a descriptive name? The name Gst means nothing to most people. It's fortunate that not all authors have the view that modules interfaced to external libs get their own TLN. There are some bad examples out there, but for each there is a good counter example, eg XML::LibXML. Randy.
Re: Name for GStreamer bindings
Torsten Schoenfeld wrote: Aloha, GStreamer is a powerful and pretty popular media framework. GNOME already uses it extensively, and KDE just started to. It's based on GLib and uses its object oriented C API style. The objects have names like GstQueue or GstElement. For similar objects like GtkWindow or GnomeIconList in other libraries, us Gtk2-Perl people tend to directly map them to namespaces: Gtk2::Window and Gnome2::IconList. For smaller libraries like libwnck or librsvg, on the other hand, we try not to pollute the top-level namespace: Gnome2::Wnck::Screen, Gnome2::Rsvg::Handle, etc. For GStreamer, I would tend towards using Gst as a namespace. It matches the C objects' names. It's short to type, which is not unimportant since it's not like the typical Perl OO module where the full package name only appears once when using the constructor -- the GStreamer bindings contain a lot of objects with their own constructors, many of which almost all programs will use. It's not directly GNOME-related. And lastly, Gst has a precedent: the Python bindings also use this namespace. On the con side, there's of course the introduction of a new top-level namespace. One that is an abbreviation and not easily recognizable. So, if you were to write Perl bindings for GStreamer, what namespace would you use? Multimedia::GStreamer I don't see any advantage of using Gst over GStreamer as a name, they both describe the same thing and GStreamer is a tad more helpfull (to google a description). Then Gnome part as mentioned seems irrelevant. Glib is possibly usefull info, but probably better conveyed via documentation as an implementation issue. It might be nice to say somethnig about what it does: plugin, pipeline... I can't think of a better word. Multimedia::Pipeline::GStreamer ??? Randy.
Re: URLs to Modules
Andrew Savige wrote:
--- Ovid wrote:
Perhaps this is a silly question that I should know the answer to, but
is there a canonical url I can list for a module and always have that
point to the latest version? Right now, my choices seem to be:
http://search.cpan.org/~$AUTHOR/$MODULE-$VERSION/
Or the awful search URL which returns too many results:
http://search.cpan.org/search?query=${MODULE}mode=module
I really feel like I should know this (grr ...)
From the late Iain Truskett's use.perl journal
http://use.perl.org/~koschei/journal/13493
---
Given a dist: DateTime::Format::HTTP
These are all the same page:
http://search.cpan.org/dist/DateTime-Format-HTTP
http://search.cpan.org/author/SPOON/DateTime-Format-HTTP
http://search.cpan.org/~spoon/DateTime-Format-HTTP
http://search.cpan.org/~spoon/DateTime-Format-HTTP-0.34
And to go straight to the module's docs:
http://search.cpan.org/perldoc?DateTime::Format::HTTP
---
Further to Iain's list above, this seems to be an alternative
way to go to the module docs:
http://search.cpan.org/dist/DateTime-Format-HTTP/lib/DateTime/Format/HTTP.pm
If anyone knows of any others, please let us know.
In addition to those listed...
Modules by author:
http://search.cpan.org/~ovid/
http://search.cpan.org/author/OVID/
Any file in a specific dist:
http://search.cpan.org/src/OVID/aliased-0.11/t/10aliased.t
or any directory in a specific dist:
http://search.cpan.org/src/OVID/aliased-0.11/t/
A specific dist:
http://search.cpan.org/dist/aliased-0.11/
I use /dist/ all the time, but rarely use /author/ and /src/ directly.
Randy.
Re: When Did a Module Become Core?
James Keenan wrote: What is the simplest way to determine for a given CPAN module (a) whether it is part of the Perl core; (b) when it became part of the core (i.e., which version of Perl); and (c) which version is considered core? http://search.cpan.org/dist/Module-CoreList/
Re: Subclassing a mailer
Scott R. Godin wrote: For a project I'm on, I'm pondering whether or not to subclass one of the various Mail::* implementations out there, with an eye for Mail::Mailer. Does anyone have any recommendations in this regard? gotchas things I should watch out for ? pointers? examples? :) I don't understand why you want to subclass Mail::Mailer. You haven't given us enough information. Are you looking to add some functionality not present in any of the mailers? What kind of functionality? Randy.
Re: MakeMaker META.yml and license
Gabor Szabo wrote: Hi, does anyone know how to add the license field to the META.yml file when using Makefile.PL ? I know how to do it from Build.PL and as far as I know MakeMake does not yet support it out of the box. Is there a workaround ? Workarounds are discussed in the thread beginning at http://www.nntp.perl.org/group/perl.makemaker/1873 Does anyone know when will MM support it ? Not sure when Michael's gonna get it in there, but Marcus has a patch in RT for it: http://rt.cpan.org/NoAuth/Bug.html?id=8561
Re: Module naming advice
David Wheeler wrote: On Jan 4, 2005, at 2:47 PM, Bruce J Keeler wrote: I've always felt that this one should have a lowercase name, since it's rather pragma-ish. Are pragmas allowed outside of the core Perl distribution? Maybe it should be submitted as a core pragma, actually. It's a really lightweight beast, and very useful. Would certainly get my vote. I agree that it should be lowercased; yes, there are modules on CPAN that look like pragmas (such as only). I personally would prefer, however, that the name tell me that it's doing something more than loading a class; class and module don't do that. Here are some other options: * alias (too close to Aliased?) * nickname * moniker * pseudonym * aka * anonym * handle (not a file handle, though, might be confusing) * label * term * shortcut I kind of like aka, actually. But nickname, moniker, and shortcut are all good, too. There is Package::Alias[1]. Does the same thing, but I haven't used it. I like the idea of it being a pragma; 'aka' seems kinda perlish. It'd be nice if this was supported in perl, so it would be possible to alias entire namespaces use aka 'Apache2::Apache::' as 'Apache::'; # ;-) Which would all all modules in the first namespace to be addressed as if they were in the second, including munging %INC so it does the right thing. 1. http://search.cpan.org/dist/Package-Alias/
Re: CPAN Testers and PREREQ_PM doesn't work very well!!!!!!
Sébastien Aperghis-Tramoni wrote: cpansmoke is being re-added for 0.050_04. What is missing now is people using/testing CPANPLUS 0.50_xx to help Jos find and crush bugs. Yeah, a more productive place to discuss this might be the cpanplus-devel list: http://lists.sourceforge.net/lists/listinfo/cpanplus-devel and/or the perl-qa list: http://lists.perl.org/showlist.cgi?name=perl-qa
New Module Idea: Starbuck's Async Message Protocol
I've just been inspired: http://www.boingboing.net/2004/12/12/starbucks_barristas_.html Starbuck's is finally getting the recognition they deserve as a great impetus and source of stimulation for the software engineer. I'll have a venti Chai Latte with a squirt of peppermint, and a script to cleanup all the week-old rss feeds from my Thunderbird mailbox, please. Randy.
Re: [rfc] File::Corruption
Joshua Hoblitt wrote: On Sun, 17 Oct 2004, Christopher Hicks wrote: On Sun, 17 Oct 2004, Joshua Hoblitt wrote: is the namespace appropriate? I'd rather see it called something like File::DetectCorruption or something that makes it clear that your module isn't here to corrupt files. That seems like a little too much typing for my tastes. File::Corruption, File::CheckSum or the like sounds better to me. File::Check File::Verify File::Validate ??? http://thesaurus.reference.com/search?q=check
Re: Let's eliminate the Module List
On 8/24/2004 9:28 AM, Simon Cozens wrote: [EMAIL PROTECTED] (Randy W. Sims) writes: hmm, are you going to generate multiple indexes? It might be interesting if we could search over the various fields provided by META.yml[1] I am only going to generate one index, but this is because Plucene indexes are better than you think they are. :) Plucene allows me to index documents with multiple fields, like so: type: module name: Email::Simple category: email author: SIMON description: ... synopsis: ... depends: rating: ... In fact, I can just index META.yml plus the documentation pretty much as is and get the data in the right fields. There's a lot more fields you can (and I will add) of course, such as when the module was released, the license, and so on. Very cool. You're right. I was thinking of the old-fashioned type text indexes. I've been doing a little reading on P/Lucene, and it's very exciting. Oooh, I think I like it I think I like what Im feelin Even though its such a surprise But you know Oooh, I think I really like it I think I like what I feel And changes really open your eyes - Boston, lyrics to I think I like it When you have such an index, to find all the good email handling modules, search for category:email rating:4-5. Or email author:SIMON, it comes to the same thing. :) Is that a bug? ;-) Browsing is just searching metadata.
Re: Let's eliminate the Module List
Andy Lester wrote: On Mon, Aug 23, 2004 at 10:43:38PM +0100, Nicholas Clark ([EMAIL PROTECTED]) wrote: There is nothing stopping anyone on this list prototyping their own improved substitute for search.cpan.org. (although it helps if you have a public facing webserver if you want to show it to others). Yet no-one does. I'm working on it. I've already pulled the minicpan (a la Randal's mini mirror) and I'm working on the Template Toolkit-fu to make reasonable pages. If anyone's interested in helping out, let me know. Looks like you and Simon should collaborate. Is it possible or realistic for it to have pluggable search browse engines. I still think sourceforge-like hierchical catagories (Topics) in META.yml would make for good light-weight search and improved by-catagory browsing (modules can list multiple catagories). There may be other usefull info in META.yml like OS Platform and requirements, etc that could be used in advanced searches. Also, some info might be pulled from cpanratings. Web development is not my area, but I've been trying to remedy that. I've been trying to setup a local cpanratings to play with and hopefully do some work on, but it's going slow right now. When I do get up to speed, I'd be willing to do some work... Randy.
Re: Which namespace for a build system?
[ Actually, I'm going ahead and CC'ing the list because I'm going to suggest something that others will probably disagree with ;-) ] Nadim Khemir wrote: -Original Message- Is this a build system for perl modules or a generic build system? Is it an application or a library? Is the documentation available; I'd like to learn more about it. It' a generic build system aimed at replacing gmake, cons and the like. I'ts a meta-build system, a nice name to tell that it is not complete :-). I'm going to suggest that it is reasonable for an application of this sort to have its own namespace. It has a very specific use, and it is not generally applicable to other perl apps. I don't like the name PBS. Probably because, if you mention it anywhere in the U.S., people the of the Public Broadcasting Corp, a publicly funded educational TV broadcasting network. PBS is a set of modules that let you build a build system. Since it's written in perl, you can add your own libraries and even have your own syntax if you wish to but the plain syntax is perl and it looks rather good and easy. The best doc to start with is the presentation I gave at perl nordic workshop the slides are on their site. In the unix perpetual tradition, the documentation is the code. Seriously, the documentation that is available is very old and very confusing. It was my goal to re-document the system this summer but I simply didn't. As there are only 2 or 3 users for the system and I know them, we haven't had the necessity to document more (the system is easy to understand as it is rule based). I want to release the system to see if there are other are interrested and in that case I will write a proper documentation. I can just about guarantee that it is not going to be used without some documentation. I suggest it is useless to post it without docs, and possibly a couple of samples. PBS is reseach project that turned wellbut I still want to do some research (like iontegration between CM and build systems) One advantage of PBS is that it is quite fun to use and build debugging is one of the base for the program. Hey, that's two ;-)
Re: Which namespace for a build system?
khemir nadim wrote: I'm going to polute witha new top level namespace! PBS:: Don't anyone have any idea of where we should put this type of modules? Is this a build system for perl modules or a generic build system? Is it an application or a library? Is the documentation available; I'd like to learn more about it. Randy. Devel:: Devel::Build:: Build:: App::BuildSystem I'd appreciate some input. Cheers, Nadim.
Re: name for singlethreaded web server framework module
david nicol wrote: I am writing a module that provides HTTP interface using select, for simple web applications without a web-server, and without POE or other modules. Configuration will be by mapping paths to coderefs. Planning to call this cute beastie HTTP::Server::Selecting. Comments? I'm not sure how descriptive Selecting is. Maybe HTTP::Server::Simple or HTTP::Server::Synchronous ? Randy.
Re: Let's eliminate the Module List
Christopher Hicks wrote: On Thu, 19 Aug 2004, Hugh S. Myers wrote: 2. Push hard on the notion of adding a keywords item to the 'standard' for pod documentation. What should those keywords be? Who decides? I'm personally much more interested in seeing a dmoz-ish hierarchy so related modules can be easily found and compared. I agree[1]. A static list of catagories like DMOZ or SourceForge uses would provide for improved, more consistent searches and an improved by-catagory browsing catalog. Catagories could be added to META.yml for easy indexing by search.cpan.org. Fixed catagories make it more likely that similar modules will be found together both when browsing by-catagory and when searching. And you eliminate the abuses of keywords. 1. http://www.nntp.perl.org/group/perl.module-authors/2601/
Re: Where do people learn how to document a module?
Hugh S. Myers wrote: Good suggestions all. OTOH---I can't help but think that it wouldn't hurt to have a few more documentation tools, for both old and new authors. I'm working on a script using B::Deparse that will when done at least generate a skeleton document framework for subs and globals. Pod::Coverage might be usefull. I think it provides a way to list all undocumented subs which in the case of the script you're talking about would be all non-private subs. Using it would guarantee that the pod generated by your script would rate as 100% covered. Randy.
Re: Mail::Vacation abondoned?
Adam Monsen wrote: (this was originally posted in comp.lang.perl.modules, but received no response) I need a vacation autoresponder that can (at least) be used within ~/.procmailrc. I'll write one unless someone knows of a useful one. Features I need: * doesn't respond to mailing lists * doesn't send to the same email more than once in a user-configurable time period * simple, useful interface (any other suggestions?) I'd like to take over the Mail::Vacation namespace and fill it with some code that works. The tests fail, it won't install, and I tried to contact the author 10 days ago and haven't heard back. Would someone please advise me on this? Would there be a better mailing list to try, module-authors possibly? If getting ownership of the namespace is just hassle, I could certainly create a new one. I am just trying to proceed thoughtfully. How about abstracting it to a general autoreply module; It's applicable to a lot of situations other than vacation. (Mail::AutoReply) Filtering based on header fields is a must, primarily for the reason you mention above, but also as a general autoreply users might want to selectively respond to messages meeting certain criteria. Another idea that comes to mind is letting it monitor remote mail (POP3) or run as a proxy in addition to running as a filter, although that might arguably be left to other modules so users can assemble them anyway they wish depending on the functionality desired??? Just some ideas, Randy.
Re: Namespace for Z-machine parse/translate module
Amir Karger wrote: --- Randy W. Sims [EMAIL PROTECTED] wrote: Amir Karger wrote: * Games::Zmachine - well, Z-machine isn't technically just for games. I say technically because the most useful Z-machine program I've seen is a Befunge interpreter. But this module is really doing more munging than gaming. This is the namespace I'd expect to find it in, but since I'm not clear on the translating part, I don't know if that should be the complete name. Let me explain. No, there's too much. Let me sum up. This is not an interpreter, where you run foo zork1.z3 and get to play Zork. Games::Rezrov does that. What my program does is take Z-machine commands like (in a simplified Z assembly language): 1220add 3 top_of_stack - local1 1225jg local1 global1a ?branch 1230call sub_foo local1 2 .branch 1235print_paddr 2a3b and translates them to: L1220: $local[1] = 3 + pop @stack; L1225: goto L1250 if $local[1] global_var(26); L1230: z_call(1476, $local[1], 2); # print You are likely to be eaten by a grue. # (I don't put a literal print in there because the text # at that address can change (within limits)!) L1250: output_text(decode_text(2a3b)); snip / This is why I was not so inclined to make this a Games:: module. As I mentioned in the original post, there have been some non-games written in Z-code. But I think a more compelling reason is that this module is parsing and translating. To me, those are more Language-y than Game-y things. On the other hand, I guess you can make the argument that the end result is a playable game. And people aren't really coding in Z-code for anything but fun at this point. Okay, I think I understand a little better now. This isn't really a Zmachine. This module deals with Zcode, transling it. So, I think I would use Zcode in preference to Zmachine in the name. I'm about 50/50 on the names Games::Zcode vs. Language::Zcode. They both make sense from a certain perspective: I would be more likely to look for it in Games::*, but it seems to fit more with the other modules in Language::*. Regards, Randy.
Re: Namespace for Z-machine parse/translate module
Amir Karger wrote: [Warnocked on cpl.modules] I've written a module that parses Z-machine files[1] and translates them into executable Perl scripts. In the future, it'll be translating to other languages: first on the list is PIR. I'd like to CPAN-ify it, and wanted to ask about namespace. That's interesting. Are the scripts then independent of the module? * Games::Zmachine - well, Z-machine isn't technically just for games. I say technically because the most useful Z-machine program I've seen is a Befunge interpreter. But this module is really doing more munging than gaming. This is the namespace I'd expect to find it in, but since I'm not clear on the translating part, I don't know if that should be the complete name. [1]For those unfamiliar with the Z-machine Long live Zork! FYI, there are lots of Zgames over at http://ifarchive.org/ and the original Zork at http://infocom-if.org/.
Re: Ratings and Reviews ne Modules
Sorry for the delay. I haven't abandoned this; it's just been a long week, and there are some issues here that I've thought of that I'm unresolved on, but I'll bring that back up another time... Eric Wilhelm wrote: # The following was supposedly scribed by # Randy W. Sims # on Saturday 24 July 2004 03:06 pm: If it does get added, does it get added to all the documentation pages or just the main documentation page? Could you give an example of what is 'main'? I mean the page with the rendered version of the pod. On my tour, I clicked the bigger-bolder link above the search-result entry (http://search.cpan.org/~lds/CGI.pm-3.05/CGI.pm) not the smaller-seemingly-less-important one below it (http://search.cpan.org/~lds/CGI.pm-3.05/). If you look at the page linked to by the less-important url, you'll see links to all the pod docs for that module. I was asking if you intended that the ratings be added the headers of all of that modules docs. To me, the former contains information which will let me make an informed decision about the module (e.g. the programmer's reference to the API which it provides) while the latter gives lots of links, ratings, test results, and related stuff, but only tells me this about the module in question: Simple Common Gateway Interface Class and I have already seen that exact information in the search-result entry. The latter links to all of the modules docs, the README, META.yml, etc. for all versions of that module. It's provides a junction point that leads to all info on that module. This is always the first place I go. I look at the README first, then the main pod. Then I can look at the META.yml if I need to check out dependencies, etc. before installing. One other thing to consider: if ratings are added to the search results page, eg. http://search.cpan.org/search?query=CGI, then placing them on the documentation page is duplicating info that has already been made available. I would also like to see a simple yes/no count in addition to the rating/reviews. If you have a list of 35 people use this::module and 700 said 'use this::other::module instead', that helps raise awareness about the other module, and allows you to make a decision more quickly based on the experiences of others. Are you referring to the amazon.com-ish N persons recommend X instead of (or in addition to) Y type recommendations? I'm not sure CPAN is worth the added complexity. I don't think the target audience is big enough to justify a lot of extra features; the ratings should be enough, but I could be wrong... [snip] I'm not sure right now how useful it would be or how many others would find it useful, but yes the N,X,Y is along the lines of what I mean. The reason that I mention it is simply that I had the idea that it might be useful in selecting modules (yes, it's a popularity contest and should be ignored in favor of an informed decision based on reading the manpage, but we can't ignore information that isn't there.) I'm sort of groping for something to 'season' the average-rating. Since I am suggesting that the average rating be displayed at the top of the manpage, I thought I should provide an idea which would allow it to mean more than 5/5 (e.g. one person rated it 5/5: 'big whoop'.) agreed. I think where ever average ratings are displayed it should include the number of reviewers, eg this module rated 4.5 stars by N reviewers. I think '600 people said it's useful' may be more helpful than one mediocre review. 60 raving reviews would tend to bend your decision more, but it's easier to get 600 people to say 'ok' than it is to get 60 to say 'this-is-great-and-here-is-why'. I'm worried about some of the items that are on the list. Some that seem obvious like adding ratings to the search results on Search I'm not sure about any more. If ratings are used to compare modules (as opposed to judging each according to its merrits), some modules might be overlooked, especially new modules. Are ratings usefull? I won't argue that reviews are usefull. And ratings provide a summary of reviews, so are helpfull in that respect. But can ratings be harmfull? ... Randy.
Re: module name for Wily (a text editor) interface client?
Sam Holden wrote: I asked this in comp.lang.perl.modules and was pointed here, so here I am. Firstly, wily[1] is a (mostly) workalike of Acme[2] an editor under plan9. Wily provides only basic functionality with a very different but very small interface (with lots of mousing, meaning many people will *hate* it). It doesn't for example have a means of doing search-and-replace (though everyone who uses wily will have an external program that adds that to it in some way). It does however, allow external programs to interface to it (and possibly add some of the missing functionality). The module I've written implements that interface and allows perl to communicate with wily. Basically it allows a perl script to interact with wily the way LISP code might interact with emacs (I think anyway, not being an emacs user). I can't work out a namespace for the module on CPAN. In fact I can't even work out a category (Commercial Software Interfaces is close, but wily isn't commercial...) Namespace wise, Text::Wily was suggested on comp.lang.perl.modules, but the module itself has almost nothing to do with text - it interfaces to a text editor which I think is a very different thing. Acme::Wily is another option, but that's subverting the meaning of the Acme namespace and putting it somewhere that makes it harder to find. I'd suggest something like: App::API::Wily Randy.
Re: Ratings and Reviews ne Modules
[Did I not reply to list in my previous message?] Eric Wilhelm wrote: # The following was supposedly scribed by # Randy W. Sims # on Thursday 22 July 2004 10:45 pm: - Module Version: 3.05 + Module Version: 3.05 Source The ratings are one click away on the dist page. Yes, but as I said on the 'tour', I don't want or need to click there unless I'm trying to download the tarball. And, since I use the command-line CPAN to do the install, I don't need to download the tarball from my browser. So, I almost *never* see that page. Lincoln D. Stein CGI.pm-3.05 CGI ^^ click ^^ ^^ here ^^ Module Version: 3.05 Source My point in putting the star-bar here --^ is that it makes the ratings visible. This accomplishes two things: 1. makes ratings more useful (e.g. while I'm reading the manpage (which is what drives the decision as to whether it is what I'm looking for) I can see the rating (and maybe I should also see a count of how many have rated it.)) 2. raises awareness about ratings (oh! there are ratings?), thus getting more people to rate/review modules. I think one of the best ways to raise awareness is to add the ratings to the search results from Search. I'm still not sure that I agree about putting it on the documentation page, but I have added it to the outline. If it does get added, does it get added to all the documentation pages or just the main documentation page? If ratings are good for anything, they are going to be taken with a grain of salt. A 5-star rating vs a 0-star rating is not going to swing me away from my own judgement. They simply give me something else to consider. I would also like to see a simple yes/no count in addition to the rating/reviews. If you have a list of 35 people use this::module and 700 said 'use this::other::module instead', that helps raise awareness about the other module, and allows you to make a decision more quickly based on the experiences of others. Are you referring to the amazon.com-ish N persons recommend X instead of (or in addition to) Y type recommendations? I'm not sure CPAN is worth the added complexity. I don't think the target audience is big enough to justify a lot of extra features; the ratings should be enough, but I could be wrong... Maybe we need to start prioritizing and weeding out the list at this point? I hope others are interested in helping to implement these improvements. I'm going to try, but I have two obstacles: 1) the usuall problem--time, and 2) this is not my area of expertise. I have no experience with CGI, setting up Apache, etc. It's an area I've never really gotten into, but I hope to use this as an opportunity to learn a little. Regards, Randy.
Re: Ratings and Reviews ne Modules
On 7/22/2004 5:50 PM, Randy W. Sims wrote: We just need to organize and do it. 1st crack at organizing ideas/suggestions made in this thread and in Ask's TODO list. Comments/Omissions? Also available at http://www.thepierianspring.org/perl/cpan-ratings.notes -- I) CPAN Ratings A) Abuse Authors abusing the system for political statements, to sabatoge authors of similars modules, etc. 1) The usuall solution is a Karma type system. Number of reviews contributed by a reviewer. Thumbs up/down for individual reviews by a reviewer (Helpfulness ratings). Thresholds on Karma that automatically invoke a moderator. 2) See also item I.C.1. B) All Reviews Pages (per module): 1) Header with average rating and other summary information. C) All Reviews Pages (per reviewer): 1) Header with reviewer information. (Obfuscated email address for one thing; try to keep people accountable). D) Searching 1) If the number of reviews per module gets large, sorting on rating/date/version may be useful. 2) Search results should include direct link to all reviews. 3) Search results should include average rating. (average per version? overall average?) 4) Allow direct search for reviews. I.E. don't send user off to CPAN Search, but do try to use it behind the scenes. E) Browsing for modules (?) 1) By module/author. F) Author's Administrative interface 1) Edit review? - Original author only. 2) Delete this review - Original author only. G) Top rated modules list - Would this encourage abuse? H) RSS Feeds 1) RSS feed of sitewide recent reviews 2) Include rating numbers in the RSS feeds 3) Subscribe to reviews of certain distributions (preferably by author) 4) Reviews of modules by a certain author (for CPANID.rss feeds) [RWS: Same as above?] I) Ratings 1) If a reviewer reviews two or more versions of a module, how are the averages calculated? 2) Expand set of rated attributes? 3) Let 'Overall' rating be calculated based on other specific attributes or let there be some additional type of 'overall' that is calulated, and let it be used in summaries--to _encourage_ a more balanced review (and discourage abuses). J) Other 1) Reviews in other languages (with filters etc). 2) Parse Embperl-2.0b9 correctly. 3) Include the other rating numbers on [some page]. II) Misc: A) Module Pages Usage tips experiences not directly related to reviews. Doesn't have to be organized around modules; it can be organized around topics (ala emacswiki). Linked to from CPAN Ratings? CPAN Search? B) Best of breed reviews. A single comparative review written on several similar modules. How would this show up in a search? Does this belong with CPAN Ratings? III) Search CPAN: A) make /d/CGI.pm work Bug seemingly in Search CPAN for CPAN.pm (others?) possibly due to '.pm' being part of name. This appears on the module dist page for links to CPAN Testers CPAN Ratings as 404 errors. B) Sorting Search results by relevance/rating. C) Searching 1) Improve searching with Keywords (META.yml)
Re: Reviewing reviewers
On 7/22/2004 11:41 PM, Eric Wilhelm wrote: # The following was supposedly scribed by # Randy W. Sims # on Thursday 22 July 2004 07:56 pm: A) Abuse Authors abusing the system for political statements, to sabatoge authors of similars modules, etc. 1) The usuall solution is a Karma type system. Number of reviews contributed by a reviewer. Thumbs up/down for individual reviews by a reviewer (Helpfulness ratings). Thresholds on Karma that automatically invoke a moderator. Okay, so if I go on a bashing-fest and then you come through and thumbs-down all of my reviews, I'll go through and thumbs-down your reviews too and then bash on your modules if I haven't made it there already. Does that trigger a karma threshold of some sort? Seems that it would be hard to detect. How about peer-review of peer-review: If I say that your review was bad, I think the next step is for you to defend your review (unless it has previously gotten a thumbs-up, in which case I must support my thumbs-down with a critique of your review.) There may be a somewhat recursive process of attack and rebuttal here, but the point is that a mean review is likely not going to be defended, and even if it had received a spurious thumbs-up, a critical dismissal of said mean review is likely to be supported rather than dismissed (thus giving weight to the dismissal and counting further towards the thumbs-down.) Recursion to level 3-or-so (pi) of the attack-rebuttal tree may invoke a moderator (or just a chanting, blood-lusting crowd/mob.) Additional weight can be given to reviewers who have posted many reviews and received many thumbs-up, etc. But, the idea behind the tree is that it localizes the debate to the review in question (rather than risk weighting solely on what may have been karma generated by a flaming disagreement about a completely different module's merits.) Absolute dead-beats can still be identified by their failure to provide a rebuttal or continually reaching level pi() with nonsensical or null arguments. I don't think anything this complicated or involved is needed. Neither am I convinced that the Karma solution is the best or a complete solution. However, This is pretty much the system that Amazon.com uses and it works pretty well IMO. Also, for this to get into back and forth arguments/bashing, the reviewers would have to attempt to track all of their reviews. The system would not provide an easy way to do that-there is no legitimate need for such a feature since the system is about reviews not reviewers. That's not to say it's not possible, but it's not easy either. I think that will discourage a large percentage of abuse, and high percentages is the best you can shoot for. Regards, Randy.
Re: [Module::Build] requires_one_of
Ken Williams wrote:
On Jul 18, 2004, at 10:08 AM, David Wheeler wrote:
On Jul 17, 2004, at 8:57 PM, David Wheeler wrote:
Agreed. I'm racking my brains (and the brains of those around me),
but I'm not coming up with anything. I like finding the right
language for things, though, so I'll have to think about it...
Hrm, I kind of like Smylers' suggested term, abstract. Maybe
abstract_requires in Module::Build?
Sorry I haven't had a lot of time to chime in - we had the baby niece
nephew over the weekend.
Unfortunately abstract is already taken in the META.yml: it's a short
descriptive phrase of the module.
Regarding the concept-formerly-known-as virtual packages, I think I'd
like them to tie into the features concept more. I think perhaps it's
time to write that boolean requirement specification stuff, and then we
can use that both in the normal requirement specs and the requirement
specs for a declared feature.
The idea would look something like this:
in the Build.PL --
features = {
# Old-style requirement spec
'yaml_support' = {
description = Can read write YAML
files,
requires = { 'YAML' = 0.13 },
recommends = { 'YAML' = 0.49 },
},
# New-style requirement mini-language spec
'dbi_support' = {
description = Can read write
databases,
requires = q{
DBI = 1.0 ,
(DBD::mysql = 1.5 || DBD::Postgres)
},
},
This method will require a complete expression parser, which is
admittably easy to implement. It just seems a little more error prone.
Also, expressions can be arbitrarily complex which can make it more
difficult to write expressions in a human readable format (David's
example hints at that complexity). That's why I liked extending the
existing format: less parsing for humans and machines.
features = {
...
dbi_support = {
description = Can read write databases,
requires = {
DBI = 1.0,
db_driver = q{ [mysql] || [pg] },
[mysql] = {
DBD::mysql = 1.5,
DataTime::Format::mysql = 0
},
[pg] = {
DBD::Pg = 0,
DataTime::Format::Pg = 0
},
},
},
This way most of the parsing is already done; Most all the terms are
already broken down into indivisible fields. It's more human readable
(IMO), though, perhaps a little more verbose. The macros help diffuse
the complexity of expressions.
Randy.
Re: Cpan Ratings
On 7/17/2004 11:36 AM, James Keenan wrote: Pardon my ignorance, but ... What is the 'default phone-home behavior' in the Makefile.PL's about which Randal was complaining? Is it the author's 'Perlish' coding style, in which he places statement-ending semicolons at the start of the line? Or something else? First, let me say that I did not intend for any names to come up, nor did intend my previous message as any type of specific accusation. I was only pointing out an example of percieved misuse that I had stumbled across a while back, and that I thought was relevant to this discussion. For anyone who wants to see the Makefile.PLs in question they can still be found on some mirrors by googling for, say, 'CGI-Builder-1.24'. Currently, I find them at http://cpan.cbn.net.id/authors/id/D/DO/DOMIZIO/. There are two separate issues here. The first, whether this author did violated some implicit moral code in the way he/she wrote the Makefile.PL. This issue only matters in that if it was something really wrong, then the reviewer might be justified in doing what he did. The behavior in question is that the Makefile.Pl will check to see if LWP is installed, and if it is try to contact the author's website to see if there is a more recent version of the module and if so to notify the user. I guess the main problem with this is that it does so without giving the user a choice. I don't agree with this behaviour. As an option it would be acceptable. Note that there is a module on CPAN that also polls for modules across the internet: ExtUtils::AutoInstall. The major difference, as it relates to this discussion, is that it polls CPAN, a known and trusted site. However, I don't think this justifies the reviewers actions. And that is the second issue, the one relevant to this discussion: Was this a misuse of CPAN Ratings? Randy.
Re: [Module::Build] requires_one_of
On 7/17/2004 12:25 PM, David Wheeler wrote: On Jul 16, 2004, at 7:48 PM, Randy W. Sims wrote: It looks like maybe we could use 'virtual' packages like I mentioned below to solve this: Erm, that should have been: YAML: requires: db_driver: [postgresql] || [mysql] [postgresql]: DBD::Pg: 0 DataTime::Format::Pg: 0 [mysql]: DBD::mysql: 0 DataTime::Format::mysql: 0 Keys in brackets (that is legal YAML isn't it?) are not evaluated until they are encountered in the value part of an expression who's key is not also a macro. Square brackets denote virtual packages or macros. This should solve all the issues you mention as far as YAML goes. The Build.PL file is much more flexible; we can express these dependencies in many ways. There is not much of an issue there. Yes, that works for me. Note that there is an implication for CPAN.pm and CPANPLUS. When a requirement with an OR condition is encountered they will have to either prompt the user for a selection or select the first option as a default. I'm not sure if there are any other compatability problems as I'm not real familiar with their implementation. But the author's should probably be consulted before making a final decision. Also, if there were a single module that all tools used to check requirements, it could include builtin macros for common virtual packages: DBD, DBM, Archiver, Encryption, ... Randy.
Re: [Module::Build] requires_one_of
David Wheeler wrote: On Jul 17, 2004, at 10:12 AM, Randy W. Sims wrote: Also, if there were a single module that all tools used to check requirements, it could include builtin macros for common virtual packages: DBD, DBM, Archiver, Encryption, ... Hrmm, yes, that would be nice, too. Did you just volunteer to write it? :-) Well, there's a rough start on one at http://www.thepierianspring.org/CPAN-Metadata-0.00_02.tar.gz that I started several months ago, but haven't had time to finish (I haven't been very productive at anything for the last couple months :-( ). Amoung other things it takes all the version checking code out of Module::Build so that it can be used by other modules. I'll try to take a look at getting polished off if it seems like a good idea to everyone. Randy.
Re: Module name? CPAN::Distribution::Depends
Robert Rothenberg wrote: I am working on a module that when given a CPAN distribution, it will determine what modules that distribution depends on by scanning the META.yml file or if that one is not present, the Makefile.PL file. A while back I started on a module to read, write, validate the META.yml file according to the spec. I'm not sure if it's usefull or relevant, but it can be found at http://www.thepierianspring.org/CPAN-Metadata-0.00_02.tar.gz. I haven't really looked in detail, but I do know that there are a lot of modules that do this using various approaches. Are you sure you have looked at them all and that none are similar enough to use or extend instead of creating another module? Like I said, I haven't really investigated myself, so I'm just asking. Is that a good name for it? I think some of the modules that perform this task are in the Module::* namespace. That's shorter and seems more appropriate. Randy. It differs from existing modules in that it merely parses the Makefile.PL file rather than try to compile or run it and look for what modules it requests. For most modules on CPAN, it is quite adequate. (The parsing module is actually Module::MakefilePL::Parse--which is already on CPAN, although that may not be the best name...) The purpose of this is for a larger project that checks testing results from CPAN Testers for a module and specific platforms. The lack of test results for some platforms is sometimes because needed modules do not work on specific platforms. This information would be useful to module authors. Thanks, Rob
Re: META.yml keywords
On 7/14/2004 3:44 PM, Mark Stosberg wrote: On Wed, Jul 14, 2004 at 03:11:11PM -0400, Randy W. Sims wrote: Fergal Daly wrote: Does META.yaml have a place for keyowrds? The spec doesn't currently provide for keywords. I do think it would be a good idea, BUT I think it needs to be done in a way to avoid abuse. I'd hate to see META.yml files grow by the kb as authors add every conceivable keyword they can think of and try to manipulate the search. The search algorithm could pay attention to the first X keywords and ignore the rest. Or at least, it could heavily weight the first few. I think this is part of how search engines prevent the same kind of above of the meta-tag keyword system. You can put as many keywords as you want into the list, but I think the search engines only really care about the first few. That seems a reasonable approach to overcoming the abuse problem. There is, however, another advantage to the catagory approach: Searching would likely be more consistent. It would help authors to place their modules so that they can be found with similar modules. It would also help ensure that users looking for a particular type module will get back a result set that is likely to contain all/most of the modules of that type. I would prefer something like this over the choosing from the fix list idea. Having free-form tags is a feature I like on: http://del.icio.us/ It allows new classifications to spontaneously appear. I will conceed that there are definate advantages to the keyword approach. Randy.
Re: META.yml keywords
On 7/16/2004 8:54 AM, Ken Williams wrote: On Jul 14, 2004, at 2:11 PM, Randy W. Sims wrote: The spec doesn't currently provide for keywords. I do think it would be a good idea, BUT I think it needs to be done in a way to avoid abuse. I think maybe it would be better to put keywords right in the pod for the module, so they become part of the documentation too. This is similar to the way they often appear in academic papers, right after the abstract - and people often find it useful for pinpointing the subject matter. Is it usefull to have in the pod? It seems like meta information to me; i.e. it seems like it would only be usefull to indexers. I am concerned that META.yml might become a huge document if everything gets put in there, but I think if we agree that it would be usefull to have keywords/catagories, then the best place is in META.yml. This also has the benefit that you can have a lightweight indexer that only has to look in one place. Randy.
META.yml keywords (was: Re: Finding prior art Perl modules)
Fergal Daly wrote: Does META.yaml have a place for keyowrds? The spec doesn't currently provide for keywords. I do think it would be a good idea, BUT I think it needs to be done in a way to avoid abuse. I'd hate to see META.yml files grow by the kb as authors add every conceivable keyword they can think of and try to manipulate the search. As limiting and as clumsy as it seems, I think that if keywords are added then it should be from a limited set of keywords, i.e. more of a classification scheme, really, where modules can appear under multiple classifications. Randy.
Re: META.yml keywords
Matthew Sachs wrote: On Jul 14, 2004, at 12:11, Randy W. Sims wrote: Fergal Daly wrote: Does META.yaml have a place for keyowrds? As limiting and as clumsy as it seems, I think that if keywords are added then it should be from a limited set of keywords, i.e. more of a classification scheme, really, where modules can appear under multiple classifications. Keywords are necessarily specific to the domain of the module, so I don't think that any global entity can designate an appropriate fixed set. For instance, my module Net::OSCAR implements the protocol used by AOL Instant Messenger, so I'd give it keywords [OSCAR, AIM, IM, AOL Instant Messenger, instant messenger, instant messaging, chat]. Classification for a module would probably be something like: Net :: Protocol Communications :: Chat :: AOL Instant Messenger (That last comes from sf.net's topic system) With the classification above AND a good one line synopsis of the module (which is already part of META.yml) most, if not all, of your keywords are covered. Randy.
Re: New module: Regexp::Trie
On 7/14/2004 5:29 PM, David Landgren wrote: Hello, I gave a talk at the French Perl Workshop in June about some work I was doing to produce really large (i.e. length($re) 5) regular expressions for Postfix access maps. (Postfix can be compiled with the PCRE library). A number of people expressed interest in the approach and wondered if and when it would be available as a module on CPAN. The idea is that sometimes you have a large set of regular expressions (e.g. 2000), and you want to test whether a string matches any of them. You don't particularly care *which* expression matches, the fact that one matches is sufficient. Brute forcing it with a loop is not very efficient. Concatenating them with | is not efficient either, if a large subset of the expressions share a common prefix. I know about Jarkko's Regex::PreSuf and another module whose name escapes me this instant, but they both suffer from the limitation of not being metacharacter-aware. For instance: use Regex::PreSuf; print presuf(qw(a\d+foo a\D+123)); produces: a\\(?:D\+123|d\+foo) The module I'm developing works with variable length tokens, and thus deals with the above correctly: use Regexp::Trie; my $rt = Regexp::Trie-new; $rt-add( qw/a \\d+ f o o/ ); $rt-add( qw/a \\D+ 1 2 3/ ); print $rt-re; produces: a(?:\D+123|\d+foo) (modulo me getting the backslashes escaped correctly here -- the algorithm does the right thing). The above example contains (IMO) too much make-work code, so I'm planning on distributing a number of helper packages as well, which will take care of the general cases. I'm thinking of something like my $rt = Regexp::Trie-new( Regexp::Trie::Lex::simple(qw( a\\d+foo a \\D+123 )) ); print $rt-re; I.e., the Regexp::Trie::Lex::* namespace, whose packages simply have to return an object that contains an 'add' method. The Regexp::Trie::new constructor will simply take the returned object and call its 'add' method until exhaustion, and fill up its own internal structure. As another example, I have a set of regexps that should never contain a bare . (dot) metachar. To do so is an error. Writing a seperate lexer package for this allows such error-checking to take place. I spoke with Nicholas Clark about the item in the latest perltodo, specifically: quote =head2 common suffices/prefices in regexps (trie optimization) Currently, the user has to optimize Cfoo|far and Cfoo|goo into Cf(?:oo|ar) and C[fg]oo by hand; this could be done automatically. /quote This is apparently a non-trivial undertaking to do in core and he suggested I pursue the release of this module regardless (I'm targetting 5.005_03 as a baseline anyway). If I haven't put you to sleep by now, I have the following questions: 1. Has this been done before (i.e. shoot me now and put me out of my misery). I haven't seen anything, but I haven't really looked either. I do see it as being a usefull module though. 2. Is Regexp::Trie a good name? (I fall into the regexp is spelt with a p camp, but if Regex is preferred that's fine by me. I can never remember which, if either, is deprecated). Definately in the Regexp::* namespace. Trie? 3. Is the lexer namespace a good idea? Or is there a better way do to this? I'm open to any design suggestions on this issue since nothing is written yet. What about Japhy's new Regexp::Parser ? Thanks for reading this far, David Landgren
Re: Future of the Module List
On 7/14/2004 5:51 PM, Tim Bunce wrote: On Wed, Jul 14, 2004 at 12:40:03PM -0500, Dave Rolsky wrote: On Wed, 14 Jul 2004, A. Pagaltzis wrote: * Dave Rolsky [EMAIL PROTECTED] [2004-07-14 19:26]: Some of them _are_ registered, but that document you're referring to hasn't been regenerated since 2002/08/27! I wish the CPAN folks would just remove it if it won't be generated regularly. Does anyone else here think that the list should probably just be done away with entirely? The _file_ should go, yes. The concept of registering modules is different. Given the fact that most authors seem to not register their stuff, the [EMAIL PROTECTED] list is slow as heck, and that the web pages never get regenerated, yes. Those are all fixable. Volunteers? The real issues are bigger and deeper. I've appended a couple of emails. Tim. On Mon, Feb 16, 2004 at 10:37:12AM +1300, Sam Vilain wrote: On Mon, 16 Feb 2004 01:32, Tim Bunce wrote; I'd like to see a summary of what those needs of the community are. (Maybe I missed it as I've not been following as closely as I'd have liked. In which case a link to an archived summary would be great.) It's very important to be clear about what the problems actually are. I don't really want to argue this side of things, I think that the problems pretty much speak for themselves. But I hate unspoken consensus, so let me suggest a few from my perspective; this applies to the combined Perl 5 modules list / using search.cpan.org: I'll play devils advocate here and point out some alternative remedies for the problems. By doing so I'm _not_ trying to detract for your suggestion, which I like, I'm just trying to show how existing mechanisms could be improved incrementally. a) searching for modules for a particular task takes a long time and unless you get your key words right, you might not find it at all. Refer the recent Mail::SendEasy thread. Calls for a richer set of categories and cross-links of some kind. (Editorial content alone is basically just more words to a search engine.) Are we talking about the same thing: perl.module-authors:2601 ? b) it is very difficult to find good reviews weighing the pros and cons of similar modules; they exist, but are scattered. CPAN ratings was a nice idea, but has too many First Post! style reviews to be useful in its current form IMHO. Argues for moderation of reviews and a minimum review length. A was this review helpful mechanism would also help to bring better reviews to the top. Also the search.cpan.org should not just show the overall rating, it should show the underlying three individual ratings (docs, interface, ease of use). This is definately a trouble area. Not long ago I was exploring the cpanratings site and discovered the unhelpful rampage by one particular reviewer http://cpanratings.perl.org/a/181. Maybe breaking the reviews into catagories would be helpful? Rate: installation, interface, robustness, overall, etc. c) it is nearly impossible to tell which modules are the wisest choices from a community size point of view; using modules that are more likely to fall out of maintenance is easy to do. Argues for more stats. I think useful *relative* download stats could be extracted from a sample of CPAN sites. Also search.cpan.org could provide relative page-*view* stats for modules. Narrow the interface for CPAN such that all viewing takes place on a single server where it can be monitored, and all download requests are distributed to mirror sites (ala sf.net). As for the best of the best, I still believe there is a lot of merrit in the list built from dependencies idea. d) some great modules are not registered (I am referring of course to such masterpieces as Pixie, Heritable::Types, Maptastic :), Spiffy, Autodia, Want ... and those are just the ones missing in my bag of tricks) Argues for fixing the registration process. This is why I am mailing you to ask: what's going on? Why is such an outdated module list being published in an authoritative location, and where can I get an up-to-date list? Module List *document* was maintained by hand. When managment of the Module List *data* was automated there was a desire to automate maintainance of the document but the document had a slightly richer structure than the data. That small hurdle meant automation never happened and the document was left unmaintained. Around the same time search.cpan.org became functional so the document had less relevance and busy people had other things to do. I'll happily conceed that the *document* isn't important these days. But I feel strongly that the *principle* (of moderated naming and categorization) is. The main pieces currently missing are: 1. Automated handling of module registration. [Where has that got to?] 2. Better integration of registration data into search.cpan.org So registration details are includes in search results, for example. 3. A 'fast path' process to
META.yml keywords (was: Re: Finding prior art Perl modules)
Fergal Daly wrote: Does META.yaml have a place for keyowrds? The spec doesn't currently provide for keywords. I do think it would be a good idea, BUT I think it needs to be done in a way to avoid abuse. I'd hate to see META.yml files grow by the kb as authors add every conceivable keyword they can think of and try to manipulate the search. As limiting and as clumsy as it seems, I think that if keywords are added then it should be from a limited set of keywords, i.e. more of a classification scheme, really, where modules can appear under multiple classifications. Randy.
Re: new module: Time::Seconds::GroupedBy
On 7/13/2004 8:01 PM, Bruno Negrão wrote: Oh, what a sadness. Indeed i never saw the DateTime project before. But still my module is far easier to use than DateTime::Format::Duration. Do you believe it is worth to publish it in Time::Seconds::GroupBy? Not sadness, experience. Actually this was an exercise on the perl QotW (Quiz of the Week) mailing list[1]. So you are not the only one to write this code and then throw it away :-) It does seem this task is adequately provided for by at least 2 other modules, so... Regards, Randy. 1. http://perl.plover.com/qotw/
Re: Perl's Sacrifice Stone
khemir nadim wrote: Hi, I started a vonlontary review on Perl Monks. I don't know if it's the best place but since they have reviews I thought it would be a good place to start with (and I couldn't think of a better place). It hasn't given any result so far :-) . If some of you would be nice enough to review the module I put there or put a module that they want to be reviewed, that might start things up. Hmm, we have: 1) Simon's code review ladder: http://lists.netthink.co.uk/listinfo/code-review-ladder 2) Ask's CPAN Ratings: http://cpanratings.perl.org/ 3) Perl Monks' Reviews: http://www.perlmonks.org/index.pl?node=Reviews Each has a slightly different focus, but there is some overlap. A part of me wonders if they should be at least loosely linked together instead of remaining 3 independant but related review tools for authors users; maybe one review site with two faces, one to help module users find modules and the other to help module authors improve their modules. Randy.
Re: ANNOUNCE: WWW::Map 0.01
Dave Rolsky wrote: On Fri, 10 Jul 2004, Scott W Gifford wrote: Right now I'm leaning towards either keeping WWW::Map or going with WWW::MapService. I think the former is actually reasonably clear given the WWW namespace, which is all about interacting with web stuff, not generating HTML or anything like that. I like WWW::StreetMap, since that's exactly what they are, and is short and unambiguous. I don't think WWW::MapService is much better than WWW:Map, but then again I don't think WWW::Map is that bad. :) Calling it StreetMap would definitively remove the possibility of making links that aren't to actual addresses, which as someone pointed out, is possible with at least MapQuest. You can plug in Minneapolis, MN and it'll give you a map of the area. I'm not sure it does. I've worked alot with mapping software (mostly DeLorme StreeAtlas and MapQuest), and I always think of a street map/atlas as a tool to _locate_ or _find_ any type _place_ or _location_ whether it by address, by place name, by postal code, by coordinates, etc. You might also (if you haven't already) consider possible extensions such as routing directions. Randy.
Re: not-so-plain documentation
On 6/24/2004 11:11 PM, Eric Wilhelm wrote:
Hi everybody!
I'm going to be documenting a system of (30+) programs with is mostly scripts,
rather than modules. I know you can just put pod text in your scripts, but
I'd like to also integrate the usage messages into the pods (or get them from
the pods.)
I've seen pod2usage() and this would work, but most of these scripts have some
defaults set for variables that can be changed with the GetOptions flags and
I'd like to show these defaults at least in the help message.
Example:
my $rounding = 0.01;
GetOptions(
'round=f' = \$rounding,
'help' = sub {usage()},
);
sub usage {
print usage: $0 filename\n;
print options: --round float (default $rounding)\n;
}
END
Since the strings printed by usage() in this case are generated on the fly,
the values which have already been set are available to be printed. With
pod2usage() and perldoc, this is not the case. Is there any way to make this
work without having to maintain duplicate information?
Preferably, something that would try to do() the file up to a certain point,
gather the variables and perform a substitution (maybe on a tag like
v$rounding.)
Yeah, I alway thought that was a weakness of the core pod modules.
Fortunately, it's easy to subclass them to do what you want. You'll want
to subclass Pod::Text, override the proper method to add a new escape
sequence (say $variable_name), then maybe override the constructor to
take a hash with the values for the variables or possibly something more
elaborate like evaling the variable name in the caller's context.
I've done similary on several occasions and it is fairly trivial. If you
have trouble, I can probably dig up an example.
Randy.
Re: New module: CGI::Tooltip
Becky Alcorn wrote: The javascript library that we're using only works in browsers as far as we know, and as far as our development goes we think of this kind of functionality as a natural extension of what the CGI module does for us. It seems that there is some overlap between the Javascript, HTML and CGI namespaces. The suggestions we have so far are: CGI::Tooltip HTML::Tooltip Javascript::Tooltip::HTML There is even a HTML::Widget and a HTML::Widgets namespace which might apply also (although which would you use?). I like HTML::Tooltip. That would be the first place I would look. It has nothing to do with CGI and Javascript is an implementation detail. HTML::Tooltip describes the module perfectly IMHO. Randy.
Re: Duplicated modules
On 5/13/2004 7:19 PM, IvorW wrote: - Original Message - From: Jose Alves de Castro [EMAIL PROTECTED] To: IvorW [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: 13 May 2004 11:23 Subject: Re: Duplicated modules Having said that, are we just reinventing Perlmonks? That, I do not know... :-| Ah, you do not know of the monastery. Check out http://perlmonks.org, which is a thriving on-line community and discussion forum, which is completely searchable. Perlmonks is not everybody's cup of tea (sorry, please excuse the UK idiom), but everyone must admit that the site has an extensive linked set of documentation, which includes numerous tutorials and FAQs which can be used as reference, even when not actively participating in the site. It would be much nicer if it was readable as a nntp or at least a mailing list; I've always found http-based discussion boardss awkward to navigate and difficult to figure out what I have and haven't read. Wonder why this hasn't been done? Randy.
Re: Module::Starter released
Andy Lester wrote: I've just released Module::Starter 0.02, meant as a replacement for h2xs. I just reinstalled Debian on my laptop with the default perl (5.6.1). The following are the modules required and requested for Module::Starter and its dependents. Not complaining or making any judgement, just thought it interesting. Archive-Tar-1.08 Devel-CoreStack-1.3 Devel-Symdump-2.03 ExtUtils-CBuilder-0.02 ExtUtils-ParseXS-2.08 Module-Build-0.24 Pod-Coverage-0.13 Pod-Escapes-1.03 Pod-Simple-2.05 Test-Builder-Tester-0.09 Test-Harness-2.40 Test-Pod-1.12 Test-Pod-Coverage-0.08 Test-Simple-0.47 YAML-0.35
Re: Module::Starter released
Andy Lester wrote: I've just released Module::Starter 0.02, meant as a replacement for h2xs. I just reinstalled Debian on my laptop with the default perl (5.6.1). The following are the modules required and requested for Module::Starter and its dependents. Not complaining or making any judgement, just thought it interesting. Archive-Tar-1.08 Devel-CoreStack-1.3 Devel-Symdump-2.03 ExtUtils-CBuilder-0.02 ExtUtils-ParseXS-2.08 Module-Build-0.24 Pod-Coverage-0.13 Pod-Escapes-1.03 Pod-Simple-2.05 Test-Builder-Tester-0.09 Test-Harness-2.40 Test-Pod-1.12 Test-Pod-Coverage-0.08 Test-Simple-0.47 YAML-0.35
Re: Module::Starter released
Andy Lester wrote:
I've just released Module::Starter 0.02, meant as a replacement for h2xs.
I think h2xs is very out of date as far as current best practices for
modules. It's also very intimidating for people who just want to create
a module, and have no need for all the compiler hoohah that h2xs throws
at you. Module::Starter is meant to make things much eaiser.
Attached is a patch with preliminary support for Module::Build support.
I added a 'builder' option for specifing whether to use M::B or
MakeMaker; default is still MakeMaker. I also added a 'license' option
as M::B likes to have it and the next version of MakeMaker will also
support it (for META.yml) although it is not in the current snapshot.
One thing that may be desirable is to add options for Build.PL and
Makefile.PL to co-exist, using one of Module::Build's compatability modes.
Another addition would be to allow module-starter to write a module for
an already created project. For example, if you create a project
'module-starter --module='Foo::Bar'', and later, you decide you need
another module to add to the existing project. 'module-starter
--module-only --module='Foo::Bar::Baz''.
Randy.
diff -urN Module-Starter-0.02-orig/Starter.pm Module-Starter-0.02/Starter.pm
--- Module-Starter-0.02-orig/Starter.pm Sun Apr 4 23:32:12 2004
+++ Module-Starter-0.02/Starter.pm Mon Apr 5 19:44:32 2004
@@ -45,12 +45,15 @@
=item * $email
+=item * $license
+
=back
=cut
our $verbose = 0;
our $force = 0;
+our $license = undef;
our $author = Module Author;
our $email = [EMAIL PROTECTED];
@@ -63,6 +66,7 @@
dir = $dirname,
modules = [ module names ],
distro = $distroname,
+builder = 'Module::Build', # Defaults to ExtUtils::MakeMaker
=cut
@@ -78,6 +82,10 @@
die Must specify an author\n unless $author;
die Must specify an email address\n unless $email;
+unless ( defined($license) ) {
+warn Defaulting to 'perl' license type\n;
+$license = 'perl';
+}
my $distro = $args{distro};
if ( not defined $distro ) {
@@ -93,7 +101,13 @@
push @files, create_t( $basedir, @modules );
push @files, create_cvsignore( $basedir, $distro );
-push @files, create_Makefile_PL( $basedir, $distro, $modules[0] );
+
+if ( $args{builder} eq 'Module::Build' ) {
+push @files, create_Build_PL( $basedir, $distro, $modules[0] );
+} else {
+push @files, create_Makefile_PL( $basedir, $distro, $modules[0] );
+}
+
push @files, create_Changes( $basedir, $distro );
push @files, MANIFEST;
push @files, 'META.yml # Will be created by make dist';
@@ -172,7 +186,7 @@
my $module_file = File::Spec-catfile( @dirparts, $filepart );
open( my $fh, , $module_file ) or die Can't create $module_file: $!\n;
-print $fh _module_guts( $module );
+print $fh _module_guts( $module );
close $fh;
print Created $module_file\n if $verbose;
@@ -301,6 +315,49 @@
print Created $fname\n if $verbose;
return Makefile.PL;
+}
+
+=head2 create_Build_PL( $basedir, $distro, $main_module )
+
+Creates a Build.PL for the given module distro.
+
+=cut
+
+sub create_Build_PL {
+my $basedir = shift;
+my $distro = shift;
+my $main_module = shift;
+
+my @parts = split( /::/, $main_module );
+my $pm = pop @parts;
+my $main_pm_file = File::Spec-catfile( lib, @parts, ${pm}.pm );
+
+my $fname = File::Spec-catfile( $basedir, Build.PL );
+open( my $fh, , $fname ) or die Can't create $fname: $!\n;
+
+print $fh HERE;
+use strict;
+use warnings;
+use Module::Build;
+
+my \$builder = Module::Build-new(
+module_name = '$main_module',
+license = '$license',
+dist_author = '$author $email',
+dist_version_from = '$main_pm_file',
+requires = {
+'Test::More' = 0,
+},
+add_to_cleanup = [ '$distro-*' ],
+);
+
+\$builder-create_build_script();
+HERE
+
+close $fh;
+print Created $fname\n if $verbose;
+
+return Build.PL;
}
=head2 create_Changes( $basedir, $distro )
diff -urN Module-Starter-0.02-orig/bin/module-starter
Module-Starter-0.02/bin/module-starter
--- Module-Starter-0.02-orig/bin/module-starter Sun Apr 4 23:17:02 2004
+++ Module-Starter-0.02/bin/module-starter Mon Apr 5 19:41:07 2004
@@ -15,21 +15,29 @@
my $distro;
my $dir;
+my $builder = 'ExtUtils::MakeMaker';
+
GetOptions(
distro=s = \$distro,
module=s = [EMAIL PROTECTED],
+builder=s = \$builder,
author=s = \$Module::Starter::author,
email=s =\$Module::Starter::email,
+license=s = \$Module::Starter::license,
force =\$Module::Starter::force,
verbose = \$Module::Starter::verbose,
version = sub { print module-starter v$Module::Starter::VERSION\n; exit
1; },
help = sub { pod2usage(1); },
) or pod2usage(2);
+pod2usage(2) unless ( $builder eq 'ExtUtils::MakeMaker' ||
+
Re: NAME field
Hans Oesterholt-Dijkema wrote: Good point. Any suggestions? With this module it's possible to have 1 Conf frontend using one of the provided backends: String, File, SQL, INI for now, but later probably Win32::Registry, maybe Wx::Config. I wasn't really concerned about namespaces when I wrote this. I like modules with short names. Anyway It would be: Config Config::String Config::File Config::SQL Config::INI (...) Config::Win32::Registry Config::wxConfig etc. Sorry, Config is a core module (see perldoc Config). Look at other modules that do what you want: Browse by catagory: http://search.cpan.org/modlist/Option_Parameter_Config_Processing Browse by module name: http://www.cpan.org/modules/by-module/Config/ Search for keywords: http://search.cpan.org/search?query=config Those are just examples, you may find more with different search keywords, etc. There are a lot of modules out there that handle config files. Research what is available. If possible use or enhance an existing module. If you really believe you have a unique module, the above research will help suggest an appropriate name. I'm not trying to discourage you, but there is already a lot of repitition and junk on CPAN. It's an authors responsibility to do the research before tossing another module on the heap. My suggestion for a name (if you find that your module offers something unique) would be Config::something, where something hints that it's a front end to multiple output formats, maybe Multi Regards, Randy.
Re: NAME field
On 4/1/2004 5:25 AM, Hans Oesterholt-Dijkema wrote: Dear All, I'm just wondering. I've uploaded a few modules last days, of which: Conf-0.06 Conf-SQL-0.05 Conf-INI-0.03 Why? There are already several namespaces where configuration type modules are located, primarily Config::*. Why do you feel the need to place your modules in a different namespace? Randy.
Re: Reshaping the modules list: a starting point, help remove the bias.
On 02/24/04 13:51, Smylers wrote: Sam Vilain writes: I've performed an initial re-work of the modules list. Please look over the sections of the list that you are most in touch with and provide feedback. After this stage, I'll try and fit the modules from the existing lists and the Phalanx project into it one by one, and see how I get on. Obviously this is a moving target; it won't be possible to change the list once now and then stick to it forever more: as modules are written the categories inevitably will have to adapt. In general it's much easier to see as new modules come along where to create (or split) categories; that also prevents premature over-splitting, to make a theoretical distinction between modules that are never written. In other words, try going through your next step of taking the Phalanx and existing list and putting the modules there into categories -- that'll show how well the categories work in practice much better than people reading though it here will be able to do. Presumably modules are allowed to be in multiple categories if they happen to do something that pertains to them? (If not the whole thing is very likely to be doomed -- people will think differently about classification, and indeed how to navigate the tree, and having to pick only a single category will lead to many people not finding what they were looking for.) Related to this, are categories allowed to make multiple appearances? This is the only sane way to deal with categories that have multiple inheritence -- DMoz (Google Directory) does this with some kind of 'symbolic link', where among a particular's category's subcategories are links to elsewhere in the tree. For example some people might think of web interfaces being under 'interfaces', so put a link there. Again this helps reduce disputes, and avoids the fruitless search for One True Hierarchy. Networking - raw communication, including IPC: You have 5 categories that all start Networking -, which suggests they collectively are really another level of hierarchy. Networking - providing services: - Server and Daemon Utilities - Web Services Frameworks: - Apache: - OpenFrame - etc, submissions welcome :) - Web Services Components: - Lots of the Apache sections from above could be moved here - Authentication, Security and Encryption: - Authentication Systems - Encryption algorithm implementations - Security interfaces It isn't clear to me exactly what these are (except for the 'Apache' stuff), and where CGI-related modules would go, including the 'bigger' run-an-entire site modules such as HTML::Mason, CGI::Application, and the wiki things. There are also many modules which exist to provide an interface to a particular website (banks, URL-shortners, search engines). Smylers I haven't read all of the previous thread, but I would think a catagory scheme like SourceForge.net would be descriptive flexible enough to provide a better long-term solution. To provide usefull information, the description tags don't neccessarily have to be hierarchical. Regards, Randy.
Re: pageranking perl modules
On 02/20/04 01:22, David Manura wrote: Since there has been some discussion recently on improving search.cpan.org search results, here's an initial attempt to apply the Google-inspired PageRank algorithm on Perl modules when interpreting module dependencies as links: http://www.math2.org/david/perlrank The top rated modules are provided below: [SNIP] This seems like a good approach; I'd be interested in seeing more of this. I think what would improve the relevency the most is a better data set. The CPAN data set was generated from the 'prereq' keys in the Module::CPANTS::asHash module, and this is only a rough representatation of the linking structure. It would have been better to download all the CPAN modules and do source code analysis directly on them. I use Randal Schwartz' minicpan script http://www.stonehenge.com/merlyn/LinuxMag/col42.html to gather statistics about metadata, to list distributions with nested Makefiles, multiple XS files, etc. (ex. http://www.thepierianspring.org/meta_stats.pl.html) The only problem is that Randal's script sometimes grabs more than just the most recent version of some modules which can skew statistics somewhat. Randy.
Re: Event::IO::Listener/Linear modules proposal
On 1/3/2004 11:22 PM, David Robins wrote: I have two modules that make use of the Event.pm module that would be more generally useful that I'd like to contribute to CPAN: Event::IO::Linear - aggregates received data into 'lines'; handles timeouts; buffers writes. Works with either Unix or Internet sockets (and presumably anything else based on IO::Socket). I'm open for new names for this one as I realize 'linear' doesn't have a whole lot to do with lines in the perl sense :. Well, perl can read a file line by line where line is defined by the _record_ seperator. So maybe it should have 'Record' in the name? Event::IO::Listener - simple server object that spawns new connections. Code is at: http://davidrobins.net/code/EventIO.tar.gz (not in CPAN distribution format yet).
Re: Licenses for Perl Distributions As Displayed on search.cpan.org
On 12/23/2003 8:21 PM, James E Keenan wrote: I recently used the Feedback section on search.cpan.org to ask the following question: I've noticed that the CPAN interface for modules now includes a space for the module's License -- but that few modules have any entry here (e.g., http://search.cpan.org/~jkeenan/List-Compare- 0.22/ http://search.cpan.org/~lds/CGI.pm-3.01/ http://search.cpan.org/~dconway/Parse-RecDescent-1.94/ ). Is this because when we use h2xs to set up the skeleton of a distribution, nothing special is done for License? Or is it because MakeMaker doesn't yet do anything for special for License in the way that it does for, say, YAML? What should I do to get something that will show up in License? Or should I not (yet) bother? Graham Barr picked up my query and was kind of enough to respond quickly, as follows: The license details are taken from the META.yml file. Both MakeMaker, Module::Build and Module::Install can all generate META.yml files. If they all support all fields, I do no know. Graham. Per consultation with people on this list, in my two CPAN distributions I have allowed MakeMaker (v6.16) to automatically generate the META.yml file, and I have not made any edits in that file once generated. The file thus generated contains no License information and, if I understand Graham correctly, that means no License info is going to show up on the search.cpan.org main page for each distribution. Is there anything I could do to generate the License info? Perhaps more to the point, at this point in the development of META.yml, _should_ I do anything about this? (I'm not losing any sleep over this. It's just that I'm always puzzled when I see License: Unknown on my distros' main pages, when I've included the standard language about same terms as Perl itself in the POD.) jimk The latest snapshot of MakeMaker does have support for a LICENSE parameter in your Makefile.PL. You could also set the NO_META flag in Makefile.PL and then manually edit the META.yml file (I dislike this option). Or, you can do the Right Think and make the switch to Module::Build :-) Regards, Randy.
Re: Simple multi-level tie
On 12/18/2003 12:25 AM, Andrew Sterling Hanenkamp wrote: Wrapping hashes with arbitrary inflate/deflate methods. This is a tool that adds syntactic sugar to hashes. I developed it for the purpose of making complicated storage in hashes tied to DBM files nicer. It doesn't matter if you use CGI::query_string, Storable, join/split, pack/unpack, or even just use this to do some kind of wacky filtering, this tool isn't a marshalling tool, it is a syntax helper. What I want to know is, is Tie::HashWrapper a good name? If you don't like that name, what might you call it? HashWrapper sounds kind of dorky to me, but that's what first came to mind and I didn't want to spend all day trying to name it, I wanted to play code monkey. It's a horrible name. Sorry. :-) The name needs to say what it is or what it's for, not how it's done. Some people hate the Tie namespace (I'm one of them), but it has become standard for tied modules. So: Tie::MLDBM::Any_* (something) or Tie::MLDBM::Custom_* (something) where * says something about having custom marshalling methods. (Store|Marshall|Format|Dump|Load|Stow|...) Regards, Randy.
Re: BTRIEVE::*
On 12/5/2003 1:05 PM, Tim Bunce wrote: Are you volunteering? Since I opened my big mouth, I guess I am. :o Now what exactly was I volunteering for again? Tim. On Thu, Dec 04, 2003 at 07:39:04PM -0500, Randy W. Sims wrote: On 12/4/2003 3:50 PM, Tim Bunce wrote: On Thu, Dec 04, 2003 at 11:42:07AM +0100, Steffen Goeldner wrote: Randy W. Sims wrote: Maybe DBMS::BTrieve::??? That looks good! But that's a new namespace. The horse has well and truly bolted on the db module namespace issue. They're all over the place. I think reusing an existing namespace is better than creating yet another one. I don't know (or can't remember) how the BTRIEVE::SAVE module got into the module list, but since it is that's the right place for new BTrieve modules. Tim. I missed that namespace. In fact, browsing http://www.cpan.org/modules/by-module/ I notice that things are /really/ getting out of hand. Maybe we need some CPAN police, volunteers for each of the domains listed at http://www.cpan.org/modules/by-category/, that must explicitly authorize new modules in that domain. Then we can have a Great CPAN Migration effort to herd some of the strays into the proper namespace. If there was just an easy procedure for migrating packages without the compatibility concerns... Randy. -- A little learning is a dang'rous thing; Drink deep, or taste not the Pierian spring; There shallow draughts intoxicate the brain; And drinking largely sobers us again. - Alexander Pope
Re: Fwd: How to put a path into a module during build time?
On 12/4/2003 12:40 AM, [EMAIL PROTECTED] wrote: Andrew Savige replied to me offlist with a good solution. Taking a hint from lib/Net/Config.pm my $file = __FILE__; my $ref; $file =~ s/Config.pm/libnet.cfg/; That is definately a more elegant solution. I only have two problems with it: 1) I did not think of it. ;) I let myself get boxed in by the question. (Must think outside the box. Time for another read of Conceptual Blockbusting http://www.amazon.com/exec/obidos/ASIN/0738205370/). 2) The purpose of a Mailing List is NOT for people to post questions and get answers. The purpose of a Mailing List is for people to post questions and *everyone* to learn from the answers. --Andrew, please share with all of us next time. =) Regards, Randy. Thank you all for your help! This may be a good question to stick in a FAQ or some documentation somewhere. This solution isn't specific to MakeMaker, and I can't say if MakeMaker is the right place for this question, but the MakeMaker docs were the first place I looked to find this answer, so who knows. Thanks again, -- Josh I.
Re: BTRIEVE::*
On 12/4/2003 3:50 PM, Tim Bunce wrote: On Thu, Dec 04, 2003 at 11:42:07AM +0100, Steffen Goeldner wrote: Randy W. Sims wrote: Maybe DBMS::BTrieve::??? That looks good! But that's a new namespace. The horse has well and truly bolted on the db module namespace issue. They're all over the place. I think reusing an existing namespace is better than creating yet another one. I don't know (or can't remember) how the BTRIEVE::SAVE module got into the module list, but since it is that's the right place for new BTrieve modules. Tim. I missed that namespace. In fact, browsing http://www.cpan.org/modules/by-module/ I notice that things are /really/ getting out of hand. Maybe we need some CPAN police, volunteers for each of the domains listed at http://www.cpan.org/modules/by-category/, that must explicitly authorize new modules in that domain. Then we can have a Great CPAN Migration effort to herd some of the strays into the proper namespace. If there was just an easy procedure for migrating packages without the compatibility concerns... Randy.
Re: when an object gets possessed by an evil spirit
On 12/3/2003 3:06 PM, Stas Bekman wrote: Obviously there is a solution to this problem. Enter the magic CLONE function called when a new thread is spawned (perl_clone is called). If a package defines this function, perl will call it. When CLONE is called Perl has already cloned $y. So what you need to do is to go and change $y's guts to point to a new C struct, initialized from the original C struct. But without changing $y, i.e. it's external appearance must not change. Only the IV slot needs to be changed. So here is where my question comes into the picture. How to call that method that will substitute the IV slot without changing the object. It's going to be used by many XS modules so we'd better choose a good name for it so we can all talk about the same method. I chose the name 'possess' as if the object 'being possessed by some evil spirit'. Remember that the external object must stay the same (since it lives in the user's space, e.g. script and we can't touch it). Liz wrote a module Thread::Bless which provides a framework for this issue, and she called this method 'fixup'. Now that hopefully you understand the problem and what the method is trying to achieve, Liz and I are trying to get more ideas from you. I'm a C++ guy, so this kinda makes me think of auto_ptr's and their reset method except that doesn't actually copy... actually this sounds more like a copy constructor; what about copy_construct() ??? But then I like possess also since it has that connotation of something magic and scarry going on... better double check those docs before invoking a possession. thesaurus says possess: bedevil, diabolize. ;) Regards, Randy.
Re: BTRIEVE::*
On 12/3/2003 11:12 AM, Steffen Goeldner wrote: Hi, I'm about to release two modules: BTRIEVE::XS BTRIEVE::API The first, BTRIEVE::XS, is a simple XS wrapper module for Btrieve's single function API. I.e., you can call Btrieve's C function BTRCALL() in perl as BTRIEVE::XS::Call(). The second, BTRIEVE::API, provides methods for common Btrieve operations (on top of BTRIEVE::XS): I agree with Nicholas, about putting it in another namespace. Maybe DBMS::BTrieve::??? Also the names shouldn't really reflect the implementation, so XS is out. And every module has an API. I don't see any reason why this all couldn't be in a single module (with an XS part and a perl part), and name it something like DBMS::BTrieve::Direct to indicate that it communicates directly with BTrieve and doesn't use DBD or ODBC, etc. Regards, Randy.
Re: when an object gets possessed by an evil spirit
On 12/3/2003 8:27 PM, Stas Bekman wrote: Randy W. Sims wrote: I'm a C++ guy, so this kinda makes me think of auto_ptr's and their reset method except that doesn't actually copy... actually this sounds more like a copy constructor; what about copy_construct() ??? Thanks, Randy. I haven't done C++ for a long time, but if I remember correctly copy_construct() is invoked on the existing object and it doesn't modify the original, but returns a new object. Here the situation is different: Perl has already invoked its copy_constructor and gave you the resulting object, so all is left is to copy the C struct and modify the passed object's IV slot. So this is sort of a copy_construct on the guts of the object... So it's more like a deepcopy_reconstructor()? Yea, I don't know a nice way to say that. But then I like possess also since it has that connotation of something magic and scarry going on... better double check those docs before invoking a possession. thesaurus says possess: bedevil, diabolize. ;) let's call it scary_function() then ;) % perldoc -f possess possess SPIRIT this function is NOOP before midnight, but after the midnight will make your code do scary things, altering the TIMTOWTDI to TIASWTDI (as in There Is A Scary Way To Do It). You must be at least 16 years old to use this function. ;) __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com -- A little learning is a dang'rous thing; Drink deep, or taste not the Pierian spring; There shallow draughts intoxicate the brain; And drinking largely sobers us again. - Alexander Pope
Re: ExtUtils::MakeMaker or Module::Build
Orton, Yves wrote: But as we start to put this together we run across Module::Build. In the past I have always used ExtUtils::MakaMaker. Is there a preference (if one were starting from scratch), to using one over the other? Personally my feeling is that Module::Build isn't mature enough for release ready code. The fact that without manual intervention what it produces isnt compatible with CPAN is IMO a serious argument against using it, and poses serious questions in my mind about its suitability in 5.10. Luckily it will be a long time before 5.10 is released, so Ken has lots of time to get it right. BTW, it shouldnt be seen that I am critical of Kens efforts, I actually think his project is quite a good idea and will eventually be an excellent replacement for older tools. But IMO it is not production worthy code at the current time. I dont know the logic behind using Build.pl instead of makefile.pl, but the fact that it doesnt create the later by defualt (or so I have been told) is in my eyes a serious mistake that will greatly reduce its overall uptake in the market. And for those people releasing code without a Makefile.pl, I wonder at the point of putting such things on CPAN. (Others such as Randal Schwartz have said the same thing) Module::Build has a compatibility feature that does in fact produce a Makefile.PL file for distribution. In addition, you can have both a Build.PL and a MakeMaker Makefile.PL if you want to go that route. Another serious issue with Module::Build is that for the last ages on Win32 it doesnt. Have a look at the transaction report of trying to install it (using itself) from CPAN. It doesnt play nicely with CPAN's prerequisite system, (a Makefile.pl program would have caused CPAN to autoload these prerequisites on my system by default) and fails build. Module::Build has worked on Windows since version 0.16 (it also now works on Cygwin as of 0.21); I ported it. Unfortunately the latest release (0.21) had some Windows bugs that I didn't catch before it was released. Despite this last release, I have found it to be very stable. There are nearly 200 distinct distributions on CPAN that now use Module::Build. And the number continues to inch upward. M::B is scheduled to appear in perl 5.10 and ultimately to replace MakeMaker, see perldelta. M::B doesn't require a make tool, so on platforms that do not include easy access to make, users can still build and install pure perl modules. I agree that the makeless make is a worthy objective, and Kens efforts are to be applauded. But IMO currently its a bit of a waste that these modules use it and are on CPAN. First off this means that they are unavailable to Win32 users, a group that make up the majority of the Perl user base (whatever the *nixens think). And for those that havent bothered including Makefile.pl's and only Build.pl's, well that code wont install cleanly from the cpan shell. Anyway, thats my take on using Module::Build. Yves I believe current releases of CPAN(PLUS)? do natively support Build.PL files, but I don't use either of them. (I prefer manual installs). I'm not arguing; I just wanted to clarify a few points. ;) Module::Build is a long way from being complete, but I think it's further along than you think, and it's catching on relatively fast. BTW, If you want to see who and what is using Build.PL, I generated a report a while back at http://sourceforge.net/mailarchive/forum.php?thread_id=245forum_id=10905 Regards, Randy.
Re: [Module::Build] (RFC) META.yml Specification Update
And here it is in pod format. =head1 NAME Module::Build::META-spec - Specification for FMETA.yml =head1 SYNOPSIS --- #YAML:1.0 name: Module-Build version: 0.20 license: perl distribution_type: module requires: Config: 0 Cwd: 0 Data::Dumper: 0 ExtUtils::Install: 0 File::Basename: 0 File::Compare: 0 File::Copy: 0 File::Find: 0 File::Path: 0 File::Spec: 0 IO::File: 0 perl: 5.005_03 recommends: Archive::Tar: 1.00 ExtUtils::Install: 0.3 ExtUtils::ParseXS: 2.02 Pod::Text: 0 YAML: 0.35 build_requires: Test: 0 generated_by: Module::Build version 0.20 =head1 DESCRIPTION This document describes version 1.1 of the FMETA.yml specification. The FMETA.yml file describes important properties of contributed Perl distributions such as the ones found on CPAN. It is typically created by tools like Module::Build and ExtUtils::MakeMaker. The fields in the FMETA.yml file are meant to be helpful for people maintaining module collections (like CPAN), for people writing installation tools (like CPAN.pm or CPANPLUS), or just for people who want to know some stuff about a distribution before downloading it and starting to install it. =head1 FORMAT FMETA.yml files are written in the YAML format (see Lhttp://www.yaml.org/). See the following links to learn why we chose YAML instead of, say, XML or Data::Dumper: =over 4 =item * Module::Build design plans Lhttp://nntp.x.perl.org/group/perl.makemaker/406 =item * Not keen on YAML Lhttp://nntp.x.perl.org/group/perl.module-authors/1353 =item * META Concerns Lhttp://nntp.x.perl.org/group/perl.module-authors/1385 =back =head1 HEADER The first line of a FMETA.yml file should be a valid YAML document header like C--- #YAML:1.0. =head1 FIELDS The rest of the FMETA.yml file is one big YAML mapping whose keys are described here. =head2 name Example: name: Module-Build The name of the distribution. Often created by taking the main module in the distribution and changing :: to -. Sometimes it's completely different, however, as in the case of the libww-perl distribution (see Lhttp://search.cpan.org/author/GAAS/libwww-perl/). =head2 version Example: version: 0.16 The version of the distribution to which the FMETA.yml file refers. =head2 abstract Example: abstract: Build and install Perl modules. A short description of the purpose of the distribution. =head2 license Example: license: perl The license under which this distribution may be used and redistributed. See LModule::Build for the list of valid options. =head2 distribution_type Example: distribution_type: module What kind of stuff is contained in this distribution. Most things on CPAN are Cmodules (which can also mean a collection of modules), but some things are Cscripts. =head2 requires Example: requires: Data::Dumper: 0 File::Find: 1.03 A YAML mapping indicating the Perl modules this distribution requires for proper operation. The keys are the module names, and the values are version specifications as described in LModule::Build for the requires parameter. INote: The exact nature of the fancy specifications like SCEgt= 1.2, != 1.5, Elt 2.0 is subject to change. Advance notice will be given here. The simple specifications like C1.2 will not change in format. =head2 recommends Example: recommends: Data::Dumper: 0 File::Find: 1.03 A YAML mapping indicating the Perl modules this distribution recommends for enhanced operation. =head2 build_requires Example: build_requires: Data::Dumper: 0 File::Find: 1.03 A YAML mapping indicating the Perl modules required for building and/or testing of this distribution. These dependencies are not required after the module is installed. =head2 conflicts Example: conflicts: Data::Dumper: 0 File::Find: 1.03 A YAML mapping indicating the Perl modules that cannot be installed while this distribution is installed. This is a pretty uncommon situation. =head2 requires_packages Example: requires_packages: - libiconv: version: 1.9 has_library: - iconv - charset has_program: - iconv - zlib has_library: - z A YAML sequence of fields whose names are the names of non-perl distributions which are required by this distribution. Each field is a YAML mapping that more specifically describes the requirement. =head3 version Example: version: 1.9 A version specification indicating the required version(s) of the required distribution. =head3 has_library Example: has_library: - iconv - charset A sequence of names of loadable or linkable libraries provided by this distribution which must be present for the distribution to be considered present. =head3 has_program Example: has_program: - iconv A sequence of names of executable programs provided by this distribution which must be present for the distribution to be considered present. =head2 dynamic_config
(RFC) (PATCH) META.yml Specification Update
Ok. So, I've gone over the spec and referenced this thread and my archives of past meta discusions on module-authors, and I've come up with a preliminary patch for Ken and anyone else interested. This is a patch against http://module-build.sourceforge.net/META-spec.html which: * Added more YAML rationale articles. * Fixed existing link to YAML discussion thread to point to new http://nntp.x.perl.org/group/ site. * Added and deprecated the private field. * Added abstract, configure, requires_os, excludes_os, and no_index fields. * Bumped version. Comments and suggestions? Randy. --- META-spec.html.orig 2003-11-13 19:02:25.0 -0500 +++ META-spec.html 2003-11-13 22:30:55.0 -0500 @@ -2,7 +2,7 @@ body h2 align=centerSpecification for the META.yml file/h2 -pThis document describes version 1.0 of the META.yml specification./p +pThis document describes version 1.1 of the META.yml specification./p p The META.yml file describes important properties of contributed Perl @@ -12,10 +12,10 @@ /p p -The fields in the META.yml file are meant to be helpful to people +The fields in the META.yml file are meant to be helpful for people maintaining module collections (like CPAN), for people writing installation tools (like a href=http://search.cpan.org/author/ANDK/CPAN/;CPAN.pm/a or a href=http://search.cpan.org/author/KANE/CPANPLUS/;CPANPLUS/a), or -just people who want to know some stuff about a distribution before +just for people who want to know some stuff about a distribution before downloading it and starting to install it. /p @@ -23,10 +23,19 @@ p META.yml files are written in the a href=http://www.yaml.org/;YAML/a format. The reasons we chose -YAML instead of, say, XML or Data::Dumper are discussed in a href=http://archive.develooper.com/[EMAIL PROTECTED]/msg00405.htmlthis +YAML instead of, say, XML or Data::Dumper are discussed in a href=http://nntp.x.perl.org/group/perl.makemaker/406;this thread/a on the MakeMaker mailing list. /p +pSee Also:/p + +ul +lia href=http://nntp.x.perl.org/group/perl.module-authors/1353;Not keen on YAML/a/li +lia href=http://nntp.x.perl.org/group/perl.module-authors/1385;META Concerns/a/li +/ul + +h3Header/h3 + p The first line of a META.yml file should be a valid a href=http://www.yaml.org/spec/#.Document;YAML document header/a like nobrtt--- #YAML:1.0/tt/nobr. @@ -56,6 +65,12 @@ The version of the distribution to which the META.yml file refers. /p +/lilibabstract/bbr +Example: bOne line description of the distribution./b +p +A short description of the purpose of the distribution. +/p + /liliblicense/bbr Example: bperl/b p @@ -129,6 +144,56 @@ distribution is installed. This is a pretty uncommon situation. /p +/lilibrequires_packages/bbr +Example:BR +b +nbsp;nbsp;libiconv:br +nbsp;nbsp;nbsp;nbsp;version: 1.9br +nbsp;nbsp;nbsp;nbsp;has_library:br +nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;- iconvbr +nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;- charsetbr +nbsp;nbsp;nbsp;nbsp;has_program:br +nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;- iconvbr +/b +p +This mapping contains a sequence of fields whose names are the names +of non-perl distributions which are required by this distribution. +A number of subfields may be provided to more specifically describe +the requirement. +/p + +ul +libversion/bbr +Example: b1.9/b +p +A version specification indicating the required version(s) of the +required distribution. +/p + +/lilibhas_library/bbr +Example:br +b +nbsp;nbsp;- iconvbr +nbsp;nbsp;- charsetbr +/b +p +A sequence of names of loadable or linkable libraries +provided by this distribution which must be present for +the distribution to be considered present. +/p + +/lilibhas_program/bbr +Example:br +b +nbsp;nbsp;- iconvbr +/b +p +A sequence of names of executable programs +provided by this distribution which must be present for +the distribution to be considered present. +/p +/li/ul + /lilibdynamic_config/bbr Example: b0/b p @@ -147,6 +212,111 @@ bring lots of security, packaging, and convenience improvements. /p +/lilibconfigure/bbr +Example: bauto/b +p +If the distribution requires configuration, this field indicates whether +the configuration process is ttinteractive/tt and requires user +intervention, ttscriptable/tt and requires intervention unless +an answer script is provided, or ttauto/tt and can configure its +self automatically. +/p + +/lilibrequires_os/bbr +Example: bdarwin/b +p +This field contains a sequence of operating system names +(ex. tt$^O/tt in perl) that are required for this distribution. +This is an implied white list such that this distribution will not +run on any operating system unless it is listed in this field. For +an alternative way to manage operating system dependencies see +bexcludes_os/b below. +/p + +piNote: If this field is specified, then bexcludes_os/b must +not be specified. +/i +/p + +/lilibexcludes_os/bbr +Example: bMSWin32/b +p +This field contains a sequence of operating system names +(ex. tt$^O/tt in perl)
Re: Tie::Array::Sorted
Simon Cozens wrote: Hi. I'm about to write a module which presents an array in sorted order; $a[0] will always be the least element by some comparator. Miraculously, there doesn't seem to be such a beast on CPAN already. Is Tie::Array::Sorted a reasonable name for it, or would another one be more obvious? Sounds like a set/multiset/bag structure. http://search.cpan.org/search?query=Setmode=all Regards, Randy.
Re: How to indicate a dependency in my module
Bruno Negrao wrote: Hi Aristotle, (in portuguese your name is written Aristteles:) I can't believe noone understood what you were talking about and went off to lala-land. :-/ :-) hehehehe lala-land, that was fun! Yes, they simply ignored what I asked them. Even if I use the technique you suggested, when an automated cpan-tester went to install my module, it will fail if it didnt have daemontools installed, right? I updated my test script avoiding it to fail if it cant find the daemontools package installed. I would like to print a warning message to the STDERR in order to advise about it, but I dont know how a cpan-tester would react if it find some output to STDERR... What do you know about it? Thanks, bnegrao I was not ignoring your problem. Other than what had already been sugested there is currently no way to elegantly solve your problem which is why I wanted to discuss alternative mechanisms to solve this problem in the future. Hopefully you will soon be able to solve your problem by editing the META.yml file in your distribution. For now your only options are to skip or fail during 'make test' or to abort during 'perl Makefile.PL'. Most module authors choose the later. Regards, Randy.
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.
Re: FAIL AFS-Command-1.3 darwin 6.8
On 11/6/2003 10:17 AM, [EMAIL PROTECTED] wrote: While I applaud the effort to automate testing of new releases posted to CPAN, this is adding absolutely no vlaue in this case. I am not looking forward to getting one of these for every platform someone decided to test this on. This particular module can NOT be tested automatically, without some manual configuration. The tests can not automatically determine the configuration of your AFs infrastructure; you have to tell me. Therefore, everytime I post this module, these tests are going to fail. The same is going to be true for DBD::Sybase, or any of the RDBMS modules which need to be configured with a data server, and/or database name. Is there a mechanism for telling the automated CPAN testing to skip this module? I do NOT want to hack the code to make the test skipped by default, because then unsuspecting administrators who install the module without reading my documentation will be give a false positive. I would prefer to have the tests fail by default, but I don't want all these emails telling me something I already know. Sounds like a job for META.yml. It would seem to be the best place to list things like: Is the module specific to a certain platform(s)? Does testing require manual intervention? Does install require manual intervention? Does the module have external dependencies? Randy. -- A little learning is a dang'rous thing; Drink deep, or taste not the Pierian spring; There shallow draughts intoxicate the brain; And drinking largely sobers us again. - Alexander Pope
