Re: to upload or not to upload...
* Eric Wilhelm enoba...@gmail.com [2010-11-11T13:54:32] # from Ricardo Signes # on Wednesday 10 November 2010 05:34: Isn't this what Net::IP does? http://search.cpan.org/dist/Net-IP/IP.pm#looping Its interface is a bit gross, but it does exist and work. That could also be said as It does exist and work, except its interface is a bit gross. Also, It does work and exist, except its interface is somewhat gross or despite an interface with some non-zero measure of grossness, it does both function and possess the property of existence. What's your point, if any? -- rjbs
Re: to upload or not to upload...
* Evgeniy Kosov evge...@kosov.su [2010-11-10T07:58:32] So, few words about what it is and why it is so. My task was to track ranges of available IP addresses (IPv6 as well as IPv4), to print reports (which addresses are free, which aren't), to be able to grab one free IP and so on. I couldn't find any suitable module (btw, is there any?), so I decided to implement one. Isn't this what Net::IP does? http://search.cpan.org/dist/Net-IP/IP.pm#looping Its interface is a bit gross, but it does exist and work. -- rjbs
Re: RFC: Hump
* Xiong Changnian xiong-c...@xuefang.com [2010-08-15T07:02:29] I'm looking to settle the namespace for a project (with the working title 'hump', verb not noun). Tentative description: *::Hump - Perl project manager and command line valet The verb hump is a childish and crude word meaning to have sex with. So, my sole suggestion is don't stick with hump. -- rjbs
Re: Trimming the CPAN
* Curtis Jewell lists.perl.module-auth...@csjewell.fastmail.us [2010-03-25T16:36:47] Me, I've been deleting as I go, and tend to keep 3 versions up on PAUSE: The previous one, the current one, and either the most recent dev version or the 2nd version back. Same, here. I use this library, which isn't good for much else yet: http://github.com/rjbs/pause-client -- rjbs
Re: Repository links in META/Pod should be http://
* Burak Gürsoy burakgur...@gmx.net [2009-10-31T18:13:05] I see that some modules have git:// protocol as the repo address in META.yml and/or Pod. I don't think this is useful to anybody since we don't see the address at all in cpan shell and hardly anyone downloads and checks every file to locate a repo. The main way to interact with such an address is the search.cpan.org site (or perldoc command if it's in Pod) and IMHO repo addresses must be http(s):// to become clickable to ease accessibility unless the repo somehow does not support http access. I think that *maybe* M::B and any other builder can also warn if the repo is not /^http/? I'm strongly opposed. There might not be any HTTP URL to my repositor, even though a CVS or Git URL may exist. There's no reason to require things to be clickably just to support some closed-source application that is only one way to access things. -- rjbs
Re: should we still be registering module namespaces?
* Jonathan Swartz swa...@pobox.com [2009-08-17T10:48:24] Is there still a point to registering module namespaces on PAUSE? In my opinion, no. The only benefit to the list is that first-time authors think it's important, so they talk to the admins of it, who can offer valuable advice for first-timers. -- rjbs
Re: Number::Format and locale woes
* Bill Ward b...@wards.net [2009-01-26T16:41:42] BE IT THEREFORE RESOLVED, that I'm seriously considering to take out Locale support from Number::Format and make it configured manually. Perhaps there may be a little locale support left in to set defaults, but only if locale isn't b0rked on that system. Sounds reasonable to me. -- rjbs
Re: Module for base 85 encoding
* Nicholas Clark [EMAIL PROTECTED] [2008-11-24T11:30:28] So I'm not sure what to call it. String::Base85 seems reasonable. -- rjbs
Re: Distribution version vs. Main package version
* Johan Vromans [EMAIL PROTECTED] [2008-11-12T18:05:39] Burak Gürsoy [EMAIL PROTECTED] writes: Well... You should either rename this thing or advertise more :) And reduce the number of prerequisites, if possible. If anything, expect more prereqs in the future. -- rjbs
Re: Distribution version vs. Main package version
* Burak Gürsoy [EMAIL PROTECTED] [2008-11-11T14:25:27] Well... You should either rename this thing or advertise more :) I'll advertise more when it's stabler. -- rjbs
Re: Distribution version vs. Main package version
* Jonas Brømsø Nielsen [EMAIL PROTECTED] [2008-11-10T16:15:20] I like to be able to release distributions without necessarily touching a code module, if changes are just documentation, tests or other files. I only update package versions when code/functionality changes, so developers using my module can depend on this version number, when examining APIs, bugs etc. I use perl-reversion (part of Perl-Version) or Dist::Zilla to keep the same version on every .pm file and the dist. It's a little annoying that the version changes on things that are unchanged, but it keeps life simple. -- rjbs
Re: Distribution version vs. Main package version
* Paul Johnson [EMAIL PROTECTED] [2008-11-10T17:17:22] I'm starting to get annoyed by the extraneous commits into the revision control system. And so I'm considering the option of not having the version number in the file that gets checked in, but expanding it for a release. Using Dist::Zilla, there is no extraneous commit. $VERSION assignment is added at 'make dist' time by dzil. The single canonical source for dist version is the dist configuration file. -- rjbs
Re: Integrating license related things of CPAN
* Ken Williams [EMAIL PROTECTED] [2008-11-02T22:55:46] Announcement: I've just committed change 12024 to Module::Build for creating a LICENSE file during the dist phase using Software::License. To get such behavior the author sets the create_license parameter to new(). In celebration of this change, I will be accepting patches or demands for new licenses to be added. Ken: is it possible to specify a S:L class directly as a license, now? I ask because the existing license keys are ambiguous. -- rjbs
Re: Integrating license related things of CPAN
* Ken Williams [EMAIL PROTECTED] [2008-11-03T09:49:01]
I noticed that, so I actually just provided explicit mappings for the
licenses M::B already knew about:
Cool. You might want to have a look at Software::LicenseUtils, which does a
reverse mapping sort of like your forward mapping:
http://search.cpan.org/src/RJBS/Software-License-0.008/lib/Software/LicenseUtils.pm
my %yaml_keys = (
perl = 'Perl_5',
apache = [ map { Apache_$_ } qw(1_1 2_0) ],
artistic = 'Artistic_1_0',
artistic_2 = 'Artistic_2_0',
lgpl = [ map { LGPL_$_ } qw(2_1 3_0) ],
bsd = 'BSD',
gpl = [ map { GPL_$_ } qw(1 2 3) ],
mit = 'MIT',
mozilla = [ map { Mozilla_$_ } qw(1_0 1_1) ],
);
That's supposed to cope with the ambiguity of things like 'gpl'. I'll post to
the cpan-metadata list about that sometime, although it looks like the problem
might be going away soon, effectively
What I would like to do next is make it more of a pure pass-through,
so that anything S::L knows about can be fed to M::B. That might
depend on having a registry in S::L, or it might mean an author could
specify a class name directly, possibly omitting the
Software::License:: prefix.
What I do in Dist::Zilla's license bit is rewrite '=Foo::Bar' to 'Foo::Bar' and
'Foo::Bar' to 'Software::License::Foo::Bar'
That allows people to specify a license class in the normal namespace or, if
they must, =MyCorp::License::MCPL.
I'd love to avoid having a registry, because it will allow people to specify
their own internal license and have all the code generate the right files.
They don't even need to bundle the library -- heck they don't even NEED to
release it to CPAN, because M::B will create the right LICENSE file. (...and
if they do release it, that's great too!)
--
rjbs
Re: Integrating license related things of CPAN
* Bill Ward [EMAIL PROTECTED] [2008-10-31T16:12:01] Instead of including a COPY of the license in every distro, how about putting the URL into the META.yml file? (Or is it URI? I always get that mixed up.) This seems like the sort of thing that URL or URI or whichever it is would be perfect for. To save what? A few bytes? Then the file will move or the server will go away, or whatever. What we really need are URNs, which don't exist and never will. It's better to put the actual text in there. I believe it's what nearly everyone prefers, anyway: packages, the authors of the license. If the cost is 1 kilobyte and that a few people add a little code to generate this file as needed, it's well worth it. -- rjbs
Re: Integrating license related things of CPAN
* David Cantrell [EMAIL PROTECTED] [2008-10-30T12:53:58] I agree that the second point is a problem. I'd like to solve it by delegating to Software::License. Anything it knows about should be a valid choice. All that does it make it Someone Elses Problem while still not solving the problem. As an example, Software::License doesn't appear to know about the Microsoft or Python licences. license: =inc::Software::License::Microsoft -- rjbs
Re: Integrating license related things of CPAN
* Dr.Ruud [EMAIL PROTECTED] [2008-10-26T06:28:44] Gabor Szabo schreef: I am trying to push forward simplifying and clarifying the licensing issues on CPAN. It would be nice to have a license pragma. use license Perl; What would this do? -- rjbs
Re: Integrating license related things of CPAN
* Dr.Ruud [EMAIL PROTECTED] [2008-10-26T14:39:23] That's up to the creator of the license pragma, but it would most probably be defined as standing for: This program is free software; you can redistribute it and/or modify it under the same terms as Perl itself. See http://www.perl.com/perl/misc/Artistic.html;. It just seems less than useful to require the loading of more code at execution time to stand in for a comment. Further, given that various packagers (Debian, etc) really really would like to see an explicit copyright in each file, it actually seems counterproductive, since authors may think that adding a 'use license' statement is sufficient. -- rjbs
Re: Integrating license related things of CPAN
* Bill Ward [EMAIL PROTECTED] [2008-10-23T15:20:00] The META.yml thing is nice but you can't make it required yet. The recommended version of Perl for production use is 5.8.8. The version of ExtUtils::MakeMaker included in 5.8.8 distributions does not support the license field. Gabor is not suggesting that it be required to upload to PAUSE, but that it be required to 'make dist.' This change would, perforce, require yet another new version of EU::MakeMaker et al. -- rjbs
Re: Integrating license related things of CPAN
* Bill Ward [EMAIL PROTECTED] [2008-10-23T17:11:09] On Thu, Oct 23, 2008 at 1:49 PM, Ricardo SIGNES Gabor is not suggesting that it be required to upload to PAUSE, but that it be required to 'make dist.' This change would, perforce, require yet another new version of EU::MakeMaker et al. Well I have no problem with that. But how about changing PAUSE? Perhaps when you upload to PAUSE without a license in META.yml it could actually replace the META.yml with one that has a license, based in input from an HTML form? Would that be too weird? I think it's technically feasible. Too many authors use one of the various cpan-upload scripts, all of which would now break. I think it's likely to be a big pain. What if the user puts a 'license X' declaration all over all the files, but forgets to include a license in META.yml. Then PAUSE puts in a default, from the user's profile? Now there is a conflict. Also, if this was set in some thing while uploading, the user would have to specify it every time? I mean, if he wanted to specify the license once and be done with it, he'd make sure he got a META.yml. The best solution will be, eventually, to reject dists without a valid META.yml. I don't think META.yml or its producers are ready for that, yet. -- rjbs
Re: Integrating license related things of CPAN
* Gabor Szabo [EMAIL PROTECTED] [2008-10-22T07:09:16] 1) META.yml license field is required. http://module-build.sourceforge.net/META-spec.html#license says the license field is required but FAIK when calling make dist or ./Build dist both EUMM and MB will happily create META.yml files without a license field. If there is an agreement on the field being required then I think the tools should not create a distribution without a valid license key. Obviously they should keep installing modules without a license in META.yml. If nothing else, it should warn. I am all for failure, though. I will tell you why. Some time ago, I picked up maintenance of Data::UUID to apply some patches. I made some releases before someone pointed out that there was no explicit license. I tried to contact the author and was unable to reach him. Nearly everyone agrees that the author meant for this to be freely redistributable and modifiable software -- it just seems too likely. That doesn't help much, though. He didn't make an explicit statement. If he'd initially make dist and gotten no license specified! do x, y, z then he would've done so, and I would have never had to bother thinking about this problem. 2) The list of valid values should be in http://module-build.sourceforge.net/META-spec.html#license instead of its current place, which is http://search.cpan.org/dist/Module-Build/lib/Module/Build/API.pod I would be really happy if we had CPAN::METAyml::Spec or something on the CPAN. 3) Software::License http://search.cpan.org/dist/Software-License/ has a growing list of licenses with full text in it. The list of licenses is not the same as the values in META.yml and even in the cases where the license seem to be the same their short name is not identical. IMHO these lists should be unified. I don't care where we get the list from so much, but we need things to be *clear*. Having license: gpl in the META.yml is not clear, because there are many versions of the GPL, and the META.yml field does not specify which is meant. The same goes for some other values. Software::License tries to be explicit. 4) Module::Starter and similar tools should use the same list (maybe taken directly from Software::License) to guide the users when they create a new module. Software::License is not entirely unrelated to some similar code in an alternative to Module::Starter, ExtUtils::ModuleMaker. Module::Starter is sort of free-form in how it allows stuff. Dist::Zilla uses Software::License directly, although I'm sure it's not well tested for things other than 'perl' license. I think all these things will be easier if we have a clearer, more explicit specification for what means what. 5) search.cpan.org is using the META.yml to display the license name. Once we have a better list it will probably reflect that. Sounds good. -- rjbs
Re: The problem with auto-installing dependencies
* Bill Ward [EMAIL PROTECTED] [2008-09-30T23:07:22] I wasn't talking specifically about anything... the recent discussion about the above led me to post, but I was talking in general about the tendency of module authors to be, in my opinion, overly eager to have dependencies on other modules. Authors are eager to (a) write less code to solve the problem at hand (b) use code that's already tested and I don't think anybody actually rushes out to add dependencies. They rush out to solve problems reliably, and they do that through code re-use. Heck, that's why you're going to the CPAN, too, isn't it? I have never added a dependency to my code when the person paying me for it asked me not to. I bet more CPAN authors are the same way. -- rjbs
Re: Module::Install is a time bomb
* Ken Williams [EMAIL PROTECTED] [2008-10-01T12:15:04] On Wed, Oct 1, 2008 at 11:12 AM, Smylers [EMAIL PROTECTED] wrote: But what if the bundled version of latest.pm is buggy and I already have a later latest.pm installed on my system? That will use the wrong one!! latest.pm doesn't ever get installed on anyone's computer. If you install it, we have a backup plan for that too - the guys in black coats will come and take your computer away. Well, at this point we're back to everybody must upgrade everything. Presumably latest.pm knows to use the installed latest.pm if it's later, even if this is rarely true and even more rarely needed. -- rjbs
Re: Module::Install is a time bomb
* Ken Williams [EMAIL PROTECTED] [2008-10-01T21:34:28] On Wed, Oct 1, 2008 at 12:02 PM, Ricardo SIGNES latest.pm doesn't ever get installed on anyone's computer. If you install it, we have a backup plan for that too - the guys in black coats will come and take your computer away. Well, at this point we're back to everybody must upgrade everything. Presumably latest.pm knows to use the installed latest.pm if it's later, even if this is rarely true and even more rarely needed. Ricardo: there's no such thing as installed latest.pm. Please go back and read what I wrote above. I read and understood what you said. Perhaps I should've said, presumably it would be better if... This thread started with Module::Install is a time bomb because, in large part, it bundles code that will not use later code found on the installing system. Then when there is a bug, every author must re-release a dist. That means that a fix to Module::Install means that there must be a thousand more upgrades, one for each dist using it. Module::Build is going to fix that by correctly using the latest Module::Build -- either the one in ./inc or the one in @INC. It will accomplish that by using code that is only found in the dist. That means that when there is a bug, every author must re-release a dist. That means that a fix to latest.pm means that there must be a thousand more upgrades, one for each dist using it. I will admit that bugs in latest.pm (which I have not seen, but can imagine) are less likely than bugs in Module::Install (which I have seen, and wish I could not imagine). It still seems sort of bizarre to have absolutely no nuclear option by which one can deal with 1,234 deployed and broken latest.pms. -- rjbs
Re: The problem with auto-installing dependencies
* Bill Ward [EMAIL PROTECTED] [2008-09-30T15:12:22] Since anyone can upload code to CPAN, not all modules are of the same high quality as others. I feel it is very important to vet each and every module that I install. But with the auto-install behavior, modules that I want to install may have dependencies on other modules that I don't feel comfortable installing, and I want to have the opportunity to consider each one before I go ahead and install it. So I don't like auto-install. I want it to stop and complain that the other module is missing, so I can go over to the CPAN Web site, look up that module, see who wrote it, read its documentation, scan its code, and get a feel for whether I'm comfortable installing it before doing so. I wish I had that kind of free time. Try setting the env var PERL_AUTOINSTALL to --check or --skip. Or --check,--skip q.v. http://search.cpan.org/src/ADAMK/Module-Install-0.77/lib/Module/AutoInstall.pm -- rjbs
Re: The problem with auto-installing dependencies
* David Golden [EMAIL PROTECTED] [2008-09-30T22:51:11] That's not what he's talking about. He's talking about modules that bundle Module::AutoInstall -- which runs CPAN.pm or CPANPLUS in a subshell during make to install dependencies. Are you sure? I think it's quite unclear. -- rjbs
Re: __DATA__ to Tempfile
* David Golden [EMAIL PROTECTED] [2008-08-01T11:37:07] I have my own unpublished version of that kind of thing that I keep meaning to release as an Archive::* module -- where a .pm file with a DATA section is the archive, including the code necessary to unpack it. And supporting multiple files, of course. It isn't what Ovid wants, and it's only part of what you want, but see Data::Section. -- rjbs
Re: Module-Starter's t/module-starter.t has skip_all
* Shlomi Fish [EMAIL PROTECTED] [2008-07-25T15:50:12]
{{
use Test::More;
plan skip_all = these tests must be completely rewritten;
}}
It also seems none of them test for the contents of the files, but only for
their existence.
These tests have *never* been used and were added by a patch that added other
features. They are a total catastrophe, and saying that they need to be fixed
is missing the point.
We should have end-to-end tests, but do not.
What can be done about it and when will it be fixed? I wanted to improve the
M-S support for software licences, but now it seems that I cannot add
regression tests for this task easily.
You can write end-to-end tests prior to adding that feature. I realize this is
non-trivial.
For my part, I think the chances of my doing this work in the next year is
nearly zero.
--
rjbs
Re: Begging for money - too tacky?
* Gabor Szabo [EMAIL PROTECTED] [2008-07-15T05:18:47] On Tue, Jul 15, 2008 at 8:15 AM, Dave Rolsky [EMAIL PROTECTED] wrote: A friend recently reminded me of the RRDB author's vast list of donations he's received for his work, and I was thinking howzabout me? might be a good idea. Make it easy to actually donate money. Refering to Payal might work but maybe you need to explicitly add your e-mail address there too. Or include a link to a page like http://rjbs.manxome.org/talks/ where people can click a button to get a ready-to-donate form. Go ahead and try that one. See how easy it is to donate! -- rjbs
Re: Template oriented module
* Ivan Wills [EMAIL PROTECTED] [2008-06-15T19:54:57] App::Cmd looks interesting but I'm not sure it does exactly what I need but will check it out further. As for App::CLI it could do with some documentation to describe what it does and how to use it. App::Cmd was largely written to do just what App::CLI does, but with more testing, documentation, and extensibility. -- rjbs
Re: Naming help - XML plist (Apple/Mac/iTunes)
* Bill Ward [EMAIL PROTECTED] [2008-06-13T04:17:26] So, I'd like to publish this on CPAN, but I'm not quite sure where to put it. I could put it under Mac:: but the iTunes/Windows option rules that out in my mind. Apple:: makes sense, but some might think that the module was produced by Apple or one of its employees which is not true. I don't know if this plist XML format is used anywhere outside of Apple software though? Would XML::PList work? Any ideas are welcome. The other plist things seem to be filed under Mac. Mac::PropertyList, Mac::Tie::PList, Mac::iTunes::Library::PList, Mac::PropertyList::SAX. I think that since almost all plist files are on Mac OS, using Mac:: for PLists parsing isn't crazy. XML::Plist would be fine, too, if you only parse the XML version. I don't think there's any point to starting an Apple::. -- rjbs
Re: Licenses of CPAN modules
* Gabor Szabo [EMAIL PROTECTED] [2008-06-04T04:50:51] - Each distro should have a META.yml and a license field in it for machines to check the license. (this one is probably not a legal requirement but it will help the various automated tools) The license field in the META.yml is insufficiently specific. It has no way of declaring what version of a license is in use. Software::LicenseUtils http://search.cpan.org/dist/Software-License/ lists the full text of some of the licenses. Maybe it is enough to make your distro dependent on Software::License and say the license is the specific version of that module? Your distro doesn't even need to require it. It would be enough if some tool knew how to resolve license: Software::License::GPL_3 when using Software::LicenseUtils 0.003 to check the license of Module::CPANTS::Analyse 0.81 - the code of CPANTS - it did not find the license. I think this happened because SLU is checking some wording and MCA had a different wording of the same intention. Yeah, it's a real hack. -- rjbs
Re: Looking for a new maintainer of my my Win32 Perl modules
* Reinhard Pagitsch [EMAIL PROTECTED] [2008-05-20T04:50:55] If no one steps up, I would be happy to put this in emailproject.perl.org's svn and take maintenance of it until someone else volunteers. I am happy if you will do it. Ok. Pass me maintainership and I will import it to our Subversion this week, and will possibly cut a new release indicating that it wants a new full-time maintainer. -- rjbs
Re: Looking for a new maintainer of my my Win32 Perl modules
* Reinhard Pagitsch [EMAIL PROTECTED] [2008-05-19T06:52:17] Mail::Convert::Mbox::ToEml: Convert Mbox to OE single eml files If no one steps up, I would be happy to put this in emailproject.perl.org's svn and take maintenance of it until someone else volunteers. Let me know. -- rjbs
Re: Feature request for PAUSE search.cpan.org: add blog URL to author profile
* David Golden [EMAIL PROTECTED] [2008-04-30T08:32:02] As I said, the easy answer is to patch PAUSE and search.cpan.org -- but the author.yml would be a more general solution for the future. That said, I'm all for saying YAGNI. I think there have been things for which AUTHOR.yml will be useful. Repository is well-placed in META.yml, though. Gosh, I should really add that to my releases. Now, to link to gitweb or git://? -- rjbs
Re: shipping extra files in a dist?
* Jerome Quelin [EMAIL PROTECTED] [2008-04-25T03:36:25] i'm writing a tk app that i'm shipping as a cpan dist. this app needs some extra resource files (icons, etc) i'd like to know what's the best method to ship extra data files in a dist. For this, I have sometimes used Module::Install::ShareDir. -- rjbs
Re: Reporting CPAN Index Problem
* David Golden [EMAIL PROTECTED] [2008-04-16T06:43:33] On Wed, Apr 16, 2008 at 5:14 AM, imacat [EMAIL PROTECTED] wrote: repository. For example, the most current version of Lingua::Features is 0.3.1, but the 02packages.details.txt.gz says: I don't know if this is the cause, but this can happen when a distribution removes a module in a subsequent release. The old module remains indexed, pointing to the old distribution that contained it. Just so. 02packages indexes all the primary packages in modules on the CPAN, and if a package only exists in a not-latest version of the distribution, then two versions of the distribution will end up in the index. This is by design. -- rjbs
Re: How to declare dependency on other modules?
* Thomas Klausner [EMAIL PROTECTED] [2008-04-11T13:07:30] On Fri, Apr 11, 2008 at 03:10:05PM +0200, Dominique Quatravaux wrote: On Fri, Apr 11, 2008 at 1:04 PM, Gabor Szabo [EMAIL PROTECTED] wrote: So if I am using Tk::Widget::A and Tk::Widget::B... Tk::Widget::Z all provided by Tk. Should I add all of them as prerequisite of my module or should I add only Tk? I'd prefer for CPANTS to allow both. TIMTOWTDI. [ ... ] And besides that, the real problem isn't within CPANTS. It is prereq'ing stuff via some 'magic' (eg prereqing 'Catalyst::Runtime'), when you actually want Catalst::Request, Catalyst::Response, Catalyst::Action and the 20+ other things in the dist 'Catalyst::Runtime' In general, listing everything is a good idea -- but there are cases where it is just too much work right now. For dists that contain dozens of modules, all of which are very unlikely to ever be split up, it's not very interesting or useful for an author to list everything he uses. Tk and Catalyst are good examples. I don't see a really good way to automate this. -- rjbs
Re: license in META.yml
* Gabor Szabo [EMAIL PROTECTED] [2008-03-31T23:09:09] Maybe there should be a module on CPAN (and maybe even distributed in core perl?) that list some of the major licenses *with their full text*. Then both Module::Build and MakeMaker could use a list exported from that module as the authoritative list for the license field. Software::License. -- rjbs
Re: license in META.yml
* David Cantrell [EMAIL PROTECTED] [2008-03-31T11:28:49] If you only care that it be free software, then you needn't bother, as that's one of the pre-requisites for something being on the CPAN. I don't believe that's actually true. Is there some requirement, when uploading, that one has agreed that anything uploaded without some OSI license attached is actually automatically licensed under the Perl 5 license, or..? You might call it a prerequisite, but unless the author has agreed to it, it isn't true. This is a problem for, say, Data::UUID where the author uploaded it with no license and then vanished, leading Debian to secretly wrap a slightly incompatible module with code called Data::UUID. [1] Among others I have talked to the Debian and Fedora packagers and they both said that one of the problematic issues with CPAN modules is the lack or incorrect license information. How can they possibly determine whether a licence is correct or not? It can conflict between the POD and the META.yml, perhaps. I would also note that the META.yml license field is insufficiently documented, and that what little documentation there is shows that the spec is buggy. This page: Agreed, whole-heartedly. This recently came up briefly in comments on Barbie's use.perl.org journal. -- rjbs
Re: RFC: URI::cpan
* Hans Dieter Pearcey [EMAIL PROTECTED] [2008-03-26T12:01:55] On Wed, Mar 26, 2008 at 11:55:11AM -0400, Guy Hulbert wrote: On Wed, 2008-26-03 at 11:36 -0400, Hans Dieter Pearcey wrote: Is there anything else that should be included? Document any assumptions about Version ordering ? This module makes none, since it makes no version comparisons. I'd expect that most applications would interpret the version-less forms of package and dist as 'latest available', but that's up to those applications. Is that true? If I ask for cpan://dist/Module-Faker, does it not canonicalize to the latest dist version? While latest package version can be gotten from 02packages, latest dist version cannot. -- rjbs
Re: RFC: URI::cpan
* Elliot Shank [EMAIL PROTECTED] [2008-03-26T14:20:20] Hans Dieter Pearcey wrote: Is there anything else that should be included? How about changing things? Kindly call it a module, and not a package, because what you're describing isn't one. Yes it is. Alternately: explain what you mean. Here is what I mean: The CPAN contains files which are dists. Each dist contains a number of files which are installed to be used as modules. Each module contains a number of namespaces which are packages. When you tell the CPAN shell to install Foo::Bar, it doesn't look for the Foo::Bar module, it looks for the Foo::Bar package, which may be located as an inner package of Foo.pm. It does this by looking up the package name in an index helpfully called 02packages.details.txt. Now, there is a quirk, which I hope to see changed: Inner packages are not indexed reliably. An inner package is indexed only if one of a few sort of weird rules are met -- but they are indexed, and appear in 02packages. Those are package names, not module names. It is a happy coincidence that in some large fraction of cases, they are the same name. Having a cpan://module/Foo::Bar would let you refer to a module, but since there is no good comprehensive index of modules, it doesn't seem very useful. -- rjbs
Re: RFC: URI::cpan
* David Golden [EMAIL PROTECTED] [2008-03-26T16:59:26] 1) Distributions can't be uniquely identified without an author name. For example: cpan://dist/Foo-Bar/1.23 Good catch. 2) dists may or may not even contain modules -- they could just contain scripts. I'm not sure this is relevant, yet. I mean, it means that things won't show up in 02packages, but that's not the end of the world. If a dist has no indexed packages, you can fall back to cpan://id/AUTHOR/... -- and if (1) above is a big problem, you'll have to anyway. 3) version numbers have no easy standards given what's out there in the wild. Consider for example: [...] I'm not even sure if CPAN::DistnameInfo really handles all the odd cases well, but it's probably pretty close to a standard for what can be done. This problem basically *has* to be a 90% solution. It sucks, but since $VERSION can be set to any old crazy thing, it's what we have to live with. 4) packages with arbitrary version numbers can't be mapped to a distribution unless it appears in 02packages.txt (latest non-developer version). If the latest Foo::Bar is 1.23, there's no way to tell what distribution tarball contains Foo::Bar 1.22. Dieter was working on a backpan index, and I know Leon has one, and BDFOY has also said he's worked on one. If it's Reliable Enough, there's that, but point taken. A) package names B1) author/distname-version B2) author/distname/version I think B1 is best dropped, because someday some jerk will upload Foo-Bar-1-2.tar.gz, version 2 of Foo-Bar-1 containing Foo::Bar:1, and now what does author/Foo-Bar-1 mean? Do we then want: 1. cpan://package/Your::Face 2. cpan://dist/HDP/Your-Face 3. cpan://dist/HDP/Your-Face/0.01 4. cpan://file/HDP/Your-Face-0.01.tar.gz (4) means that you can't use cpan:// to find a non-author file, like 02packages itself. There could be //file and //userfile. Or something. (2) would refer to the dist per se, not anything like latest version I agree, though, that 2 and 3 have their own problems. If the backpan indexing is a success, then we may end up with: 1. cpan://package/Your::Face 2. cpan://package/Your::Face/0.01 3. cpan://file/HDP/Your-Face-0.01.tar.gz If the backpan indexing is a success, then possibly it can be made possible to allow install Your::Face 0.01 to force and old version from the backpan. -- rjbs
Re: RFC: URI::cpan
* David Golden [EMAIL PROTECTED] [2008-03-26T18:02:55] On Wed, Mar 26, 2008 at 5:23 PM, Ricardo SIGNES 5. cpan://index/02packages.txt.gz That could be used as a uniform way to address index files scattered across the authors/, modules/, and indices/ directories. I don't like file because that's not the only way to address files. I would do (4) like this: 4a. cpan://author/HDP/Your-Face-0.01.tar.gz Yes, both good. (2) would refer to the dist per se, not anything like latest version That's what I don't really get. What does that *mean*? If a URI is supposed to identify a resource (c.f http://en.wikipedia.org/wiki/Uniform_Resource_Identifier), what resource does (2) identify? I said latest because that attempts to pin it to a specific resource. In the abstract, it doesn't seem to have any standard meaning and thus no real utility. What's the use case? Maybe that will help us pin it down. I am going to be verbose and pedantic. Please know that I am not trying to sound like a jerk: In the CPAN, there are dists, which are largely any understood archive, but especially one that contains either META.yml or is laid out with modules and other stuff we recognize. META.yml helps make clear what a dist is. Dists have prerequisites. Packages don't. That's why it's important to have a dist as a thing. So, I think we agree already that a versioned dist, probably almost analagous to the archive containing it, is a thing. Is a dist name also a thing? I think so. In our project, which does things like say, this version of this dist has these packages as prerequisites, can end up with a lot of mappings like this: [ Dist, Version ] - [ [ Package, Version ], ... ] - PAUSE id - other meta information Using the dist name alone lets you point to the group of all dists using that name as their name. This is already useful! http://search.cpan.org/dist/SOAP-Lite It shows me a dist, with a listing of all of the currently available versions, even if they are not the source of packages that end up in 02packages! It also happens to show me information about the most recent uploaded one, or possibly the one with the most recent indexed packages, etc. Still, the dist name alone is a useful resource locator. I can also imagine: knight!rjbs:~$ cpan-idx viewdist SOAP-Lite showing me a listing of specific versions. Now, you were right: it's totally possible for both of us to upload distinct dists that both claim to be Foo-Bar version 1, with distinct packages provided. I don't know what search.cpan.org does in this case, but it is not an unsolveable problem. The complete specifier for a dist is -- by gum -- the locator for the file! Still, the dist name itself *is* a useful locator. Now, is this useful? cpan://dist/Foo-Bar/1.2 I don't know. It would be all dists with the given version and name. In nearly every case, I imagine, that will be one dist. Sometimes it will be two. It would be pretty cool to let a tool, with a good index available, resolve that into a file if possible and (depending on the use case) into many files or an exception if not. knight!rjbs:~$ cpan-idx unpack cpan://dist/Foo-Bar/1.2 cpan-idx: Sorry, there are two dists available for that locator: * cpan://author/RJBS/Foo-Bar-1.2.tar.gz * cpan://author/DAGOLDEN/Foo-Bar-v1.2.zip Is this only useful when a good index has been constructed? Yes. I think that's fine. *** Summary -- proposed definitions *** 4) Distribution -- refers to a distribution tarball indexed in 02packages; could include an optional version; if the data were available, it could refer to any distribution ever indexed in any 02packages file historically; Without a distribution name or author, refers to all indexed distributions or all indexed distributions by a particular author: My disagreement with this should be clear from the above. I think that using 02packages as a source for distribution indexing is going to be a losing proposition. What do you think? Mostly, I agree with you! -- rjbs
Re: RFC: URI::cpan
* David Golden [EMAIL PROTECTED] [2008-03-26T21:00:01] On Wed, Mar 26, 2008 at 8:26 PM, Ricardo SIGNES In the CPAN, there are dists, which are largely any understood archive, but especially one that contains either META.yml or is laid out with modules and other stuff we recognize. META.yml helps make clear what a dist is. Dists have prerequisites. Packages don't. That's why it's important to have a dist as a thing. * tarballs without META.yml become badly formed distributions Just so. We can politely call them legacy distributions, in many cases. :) * the name parameter in META.yml is the key to indexing distributions. Distributions that use a name that has already been claimed by a prior META.yml could be treated as unauthorized the same way package namespace collisions work today. That would help disambiguate names Maybe... this may require further thought. The fact that nothing claims dist names now lets us avoid having to worry about it. Each uploaded dist with a given name is just another branch. * a distribution tarball name should be the concatenation of its name and version from META.yml followed by an archive suffix. That doesn't exist as a Kwalitee metric, but could/should be added. Agreed. * the META.yml spec could/should be revised to include a uploaded_by item that must be the CPAN author ID of the person who uploaded it. That would allow the physical location in a CPAN repository to be determined pretty exactly just from a META.yml Yeah, in writing Module::Faker, this became clear to me. Instead, it goes into the Faker-specific data for now. I'd love to start a dialog about tweaks to META.yml sometime soon, possibly amongst friends in a Scandinavian wonderland... My disagreement with this should be clear from the above. I think that using 02packages as a source for distribution indexing is going to be a losing proposition. From my comments above, I think we're now in agreement. Verbose and pedantic helped. At this rate, I'll never learn to stfu! -- rjbs
Re: List::oo - object interface to list methods
* Eric Wilhelm [EMAIL PROTECTED] [2007-10-22T02:10:07] Anyway, now it has a full set of bindings for everything (I think) in List::Util and List::MoreUtils. Seems a good bit like http://search.cpan.org/dist/Object-Array/, but with a shorter constructor. A SEE ALSO with a comparison would be nice. -- rjbs
in search of author: AVATAR, Config::Ini
I'd like to use Config::INI for common information about Config::INI::Reader and Config::INI::Writer. Config::Ini is module-list registered for AVATAR, who has not made a CPAN release in five years. I've sent him an email (a few weeks ago) but heard nothing back. Any leads? -- rjbs
Re: In which linux distribution is my module available
* Xavier Noria [EMAIL PROTECTED] [2007-05-04T04:38:14] On May 4, 2007, at 10:26 AM, Gabor Szabo wrote: A few days ago I created a report listing the availability of every CPAN module as package in various Linux distributions. A bit more work on it and now there is a report for each module author as well. http://www.szabgab.com/distributions/ Thank you! How do you people interpret the difference between FreeBSD and the rest? When I saw this report, I posted an angry version of your question to my journal, and got a well-tempered response from tagg: http://use.perl.org/~rjbs/journal/33170 -- rjbs
Re: Net::Server::Mail
* Xavier Guimard [EMAIL PROTECTED] [2007-03-27T15:30:46] The last I published correct bugs reported since 1 year. Since there is no response, I've reported the bug in Debian but it is not critical and my patch will not be taked into account: the Debian maintener waits for official upgrade, so I can not use Debian security upgrade without survey if this library is upgraded. So is it possible to change Net::Server::Mail PAUSE maintener ? Xavier, I can't help you, but! If you do take maintenance over this module, please consider housing it in the Perl Email Project SVN repository so that in the future it is easier to pass along to new maintainers, along with the rest of the PEP code. http://emailproject.perl.org/wiki/Getting_Involved PS: I you can see, I'm not a native english speaker, so excuse me for my poor english... ;-) Your English is quite good! -- rjbs
Re: Custom extensions to META.yml
* brian d foy [EMAIL PROTECTED] [2007-03-04T12:09:26] I'm not talking about the particular field name, but the idea that I'd want to say in META.yml Don't send me mail, or whatever setting I want. Instead of having to disable (or enable) CC for every new tool, I'd want a setting that new tools could look at without me having to change the META.yml in all of my distributions then re-uploading them all. So, for some subset of META.yml settings, you could consult the module's author settings, found at (say) $MIRROR/authors/.../RJBS/METAMETA.yml That would be on your local mirror, be it minicpan or CPAN-over-HTTP. Something like that? I feel a potentially irrational sense of dread. -- rjbs
Re: Custom extensions to META.yml
* David Golden [EMAIL PROTECTED] [2007-02-28T22:39:01] Is there a de facto standard for custom extensions to META.yml? (I didn't see one in the spec.) An example might be fields beginning with a capital letter or X-foo style extensions. E.g. Why not: extensions: CPAN::Reporter: cc_author: 0 (PLEASE let's avoid 'yes' and 'no' as booleans.) If all the extensions are under the module (or, hey, dist) that uses them, then the X-nonsense is avoided. -- rjbs
Re: Give up your modules!
* Gabor Szabo [EMAIL PROTECTED] [2006-08-14T07:00:10] e.g. a big red sign on search.cpan.org next to each module that has open bugs in RT and has not been updated for the past 6 months... I use this script to find bugs in mail-handling code or code I maintain. http://rjbs.manxome.org/hacks/perl/bugagg -- rjbs signature.asc Description: Digital signature
Re: Why is module list not more up-to-date?
* James E Keenan [EMAIL PROTECTED] [2005-11-28T22:08:47] I notice that the timestamp on this page says: Fri Nov 18 22:56:49 2005 GMT ... 10 days ago. And this appears to be the date that my CPAN.pm is using as a reference point. There's some sort of drive failure in the CPAN's master mirror. Unfortunately, it has not been written about here, yet: http://log.perl.org/ -- rjbs pgpY0iDuVWolL.pgp Description: PGP signature
Re: Another CPANTS/pod_coverage.t rant - FULL VERSION
* David Golden [EMAIL PROTECTED] [2005-11-14T08:56:32] Pod syntax checking is there already as testpod. It would be fairly trivial to add testpodcover, but I suspect that never happened because testcover does it already through Devel::Cover. Test::Pod::Coverage needs to evaluate the Perl code it is coverage-testing. It has been said that no CPANTS test will do that. -- rjbs pgp2xfUu1Cydq.pgp Description: PGP signature
Re: Module abstract: Is its length still limited?
* Andreas J. Koenig [EMAIL PROTECTED] [2005-11-07T17:29:50] I will be very happy if you guys decide something and let me know. I'll adjust the code for the forms on PAUSE then. Here's my official vote: (length $module_name + length $abstract + 3) should be under 80. This means that the whole header and abstract will fit in one line. That's more than 44 characters for short module names. Longer module names, which should be pretty descriptive, need shorter abstracts. Wombat - a framework for building reusable fruit-counting applications Application::Framework::FruitCounting - for reusable produce applications -- rjbs pgpRf2F6cYoOK.pgp Description: PGP signature
Re: Module abstract: Is its length still limited?
* James E Keenan [EMAIL PROTECTED] [2005-11-04T18:22:57] Since the 44-character limit never applied to modules except those intended for CPAN, and since it does not now appear to apply to modules as they appear on search.cpan.org, I'm inclined toward the latter approach. Comments? I think that's the right thing. I see modules, sometimes, with incredibly long abstracts: Numbers::Add - take two numbers from a user and then use mathematical techniques to produce a sum and return that sum via the return builtin You might want to warn about very long abstracts, but 44 seems excessively short to warn, let alone error. -- rjbs pgpsFjo5Somd7.pgp Description: PGP signature
Re: RFC - Test::Stupid module
* Robert Rothenberg [EMAIL PROTECTED] [2005-08-20T18:58:25] The problem is that authors use boilerplates. With Module::Starter there are lots of modules with abstracts The great new [modulename]. No matter what wiz-bang new module starter system somebody comes up with, there will be some kind of boilerplate text. Unless maybe it asks you to write the documentation before you write the module. (Fine for some developers, but not everyone.) What do you think about Module::Starter also building, by default, a test file that checks for the boilerplate text? -- rjbs pgpeew6qmBO0o.pgp Description: PGP signature
Re: Should DSLIP codes be updated?
* Robert Rothenberg [EMAIL PROTECTED] [2005-03-29T18:03:09] On 29/03/2005 22:14 Andy Lester wrote: Or thrown away entirely, along with the rest of the archaic idea of module registration. I'm sympathetic to the idea, but some of the information in DSLIP is useful and shouldn't be thrown away (such as how supported, alpha/beta/mature, and license). What isn't in META.yml should go there. I assume you mean What isn't in META.yml should go in DSLIP. Why not What isn't in META.yml should go in META.yml? No reason every module that wants to provide this information can't. -- rjbs pgpsQatgjrGuz.pgp Description: PGP signature
Re: Should DSLIP codes be updated?
* Robert Rothenberg [EMAIL PROTECTED] [2005-03-29T14:16:11] Some food for thought and debate. I'm wondering if the DSLIP codes [1] be updated, if revamped altogether. Note the following issues: I vote for eliminated. -- rjbs pgpxUKHHyPWvh.pgp Description: PGP signature
Re: Introduction Letter
* Andrew Savige [EMAIL PROTECTED] [2005-02-28T04:22:04]
This function synonym:
sub run { prun( @_ ) }
is better implemented as:
sub run { prun }
...which, in turn, is better implemented as
sub run { goto prun }
because it will never have to return to run. The return value of prun
will be returned directly.
Or, finally:
*run = \prun
which will just make calls to run invoke prun directly.
--
rjbs
pgp66ooVqWZSK.pgp
Description: PGP signature
