Re: RFC - Test::Stupid module
In article [EMAIL PROTECTED], A. Pagaltzis [EMAIL PROTECTED] wrote: * _brian_d_foy [EMAIL PROTECTED] [2005-08-22 20:00]: Sure, but you and brian arenât the kind of people whoâd need h2xs or module-starter or the like anyway. I find it kind of strange to be telling people without enough experience to possibly roll their own yet to do just that. I'm telling people to use their favorite module tool to create a smaple distribution, templatize it to fix the boilerplate, then use their own templates. I am nto telling people to make their own module starter tool. For people who need h2xs, the difference between them not understanding what h2xs does and what my solution does is not going to matter that much. Both ways give you a directory of files whether you understand the files or not. -- brian d foy, [EMAIL PROTECTED]
Re: Checking for boilerplate
In article [EMAIL PROTECTED], Andy Lester [EMAIL PROTECTED] wrote: On Wed, Aug 24, 2005 at 07:46:38AM -0500, Ken Williams ([EMAIL PROTECTED]) wrote: Personally I still don't think that's the best place for it. Why make all the people who *download* your module check something that should be checked at make dist time? Did people not like the idea of putting these checks as plugins into Module::Release? We saw putting it in Module::Starter as a place to start. JFDI and all that. Well, each module making tool is going to have to tell someone what its boilerplate looks like. I think each module tool will have to have it's own boilerplate.t, so each tool might as well make its own. However, with the right interface, a Module::Release plugin could get that boilerplate.t from the module tool. :) -- brian d foy, [EMAIL PROTECTED]
Re: RFC - Test::Stupid module
In article [EMAIL PROTECTED], A. Pagaltzis [EMAIL PROTECTED] wrote: * _brian_d_foy [EMAIL PROTECTED] [2005-08-20 23:15]: When you want to add something (like a standard test file), you just add it to the sample dist. When you want to change some boilerplate, you just change it in the sample dist. When you want to move files around, well, you get the idea. Using a tool from CPAN is not conceptually different from what youâre doing, but a good way for developers who havenât developed specific needs and wants (yet) to get a headstart on doing things properly. It is completely different. A tool from CPAN is somebody else's idea of what your module distro should look like. Mine, not being a module starter tool, is your own idea. It doesn't know anything about modules other than what you tell it. -- brian d foy, [EMAIL PROTECTED]
Re: RFC - Test::Stupid module
In article [EMAIL PROTECTED], Robert Rothenberg [EMAIL PROTECTED] wrote: I'm rather annoyed by the spate of CPAN uploads which have defaults from h2xs or Module::Install that are not edited, things like Perl extension for blah blah blah or A. U. Thor. In other words, stupid mistakes. So I've been toying ideas for a module which checks for files which match regexps of known defaults. Better yet, stop using those module starter utilities. Last year I went through this boot-strapping process: * Use one of module starter utilities to make a sample dist. * Turn that dist into a directory of Templates. Make everything just like you like it, boilerplate and all. Put files where you like them. * Process the whole thing with ttree when you need a new module. * If you want to add a new file, you just process that template from your sample dist. When you want to add something (like a standard test file), you just add it to the sample dist. When you want to change some boilerplate, you just change it in the sample dist. When you want to move files around, well, you get the idea. I wrote about this last December for TPJ. http://www.tpj.com/archives/2004/0412/ But, I notice you have to pay to see that. It's pretty easy to figure out on your own, though. -- brian d foy, [EMAIL PROTECTED]
Re: Probing requirements (was: Re: Some ideas)
In article [EMAIL PROTECTED], Randy W. Sims [EMAIL PROTECTED] wrote: Probe::OS - Gather info on the operating system Probe::Libs Probe::Progs Probe::FileSys - maybe incorporate ideas Schwern posted on p5p recently, Perhaps we can put this under a namespace like Config:: ? I imagine that these modules could be useful in a lot of other areas, especially in the sysadmin realm. :) -- brian d foy, [EMAIL PROTECTED]
Re: CPAN cruft cleanup?
In article [EMAIL PROTECTED], Christopher Hicks [EMAIL PROTECTED] wrote: On Wed, 23 Feb 2005, Johan Vromans wrote: But from what I hear, I'm on my own -- Not completely. The cpancd[1] package has the functionality in it to find out the latest version of a series of versions. Although the package is obsolete (CPAN won't fit on a CD anymore), this function could be useful. But CPAN might fit on a couple of CD's or a DVD. CPAN is around 3 Gb total, which is up from about 2 Gb a year (or so) ago. The rate of uploads is also increasing, so pretty soon a DVD will even be too small :) Authors should just get rid of old distros. They'll always be in the BackPAN. -- brian d foy, [EMAIL PROTECTED]
Re: CPAN::Forum
In article [EMAIL PROTECTED], Bruce J Keeler [EMAIL PROTECTED] wrote: On Wed, 2005-02-02 at 20:06 +, Nicholas Clark wrote: I can't think of a future-proof way of avoiding IDs you allocate conflicting with PAUSE, unless you and Andreas collaborate CPAN IDs are always uppercase, if I'm not mistaken. The new forum currently requires registrants to use lowercase names. Problem solved. except that i still want bdfoy to be me, and merlyn to be Randal, and so on. If we are going to discuss modules, it's just simpler to have the login name of the owner match the CPAN id of the owner. RT.cpan.org makes it work, so CPAN::Forum can too. :) -- brian d foy, [EMAIL PROTECTED]
Re: Including a 480K data file with a module
In article [EMAIL PROTECTED], Scott W Gifford [EMAIL PROTECTED] wrote: Why not just leave it uncompressed, and let the compression of the whole package into Geo-PostalCode-US-0.1.tar.gz take care of compressing it? I recommend not doing that. I had a lot of problems distributing the data for Business::ISBN with the code. Most notably, installing the module overwrote any updated data the user had added. -- brian d foy, [EMAIL PROTECTED]
Re: Including a 480K data file with a module
[[ This message was both posted and mailed: see the To, Cc, and Newsgroups headers for details. ]] In article [EMAIL PROTECTED], Scott W Gifford [EMAIL PROTECTED] wrote: I'm working with T.J. Mather on updating Geo::PostalCode. One of the things we're looking at is how to manage the ZIP code database that's necessary for its operation. I eventually bundled the ISBN data for Business::ISBN separately. Geo::IP has a separate and updatable data file which users need to download separately. That's the way to go I think. -- brian d foy, [EMAIL PROTECTED]
Re: Including a 480K data file with a module
In article [EMAIL PROTECTED], Dana Hudes [EMAIL PROTECTED] wrote: On Tue, 4 Jan 2005, Scott W Gifford wrote: A private emailer wrote: [...] Even better isn't all this on a USPS server? Whatever tool you use to grab their server database, include it and do that as part of the build process or perhaps offer it as an option , the alternative being to go to the USPS server every time. Three things I don't like about that. First, it gives a single point of failure for the system, the alternative is stale data. The USPS server is authoritative. It may be authorative, but it certainly is slow. I would like a data file that I can use without a net connection and for several thousand records. I don't want to make several thousand requests to a web site. I guess it comes down to how often the ZIP codes change. I have no idea but of course its less frequent than the registry of .COM . You can always offer a tool in the scripts/ directory of your code distro to build the database from the Internet. That addresses your cache issue. The USPS folks offer all the data on CD. Those of us that really care about such things would rather just build it from those files, I think :) In Business::ISBN::Data, I included the script I used to convert the information from the ISBN folks to the data file I needed. Failing that, instructions are the next best thing. -- brian d foy, [EMAIL PROTECTED]
Re: CPAN Testers and PREREQ_PM doesn't work very well!!!!!!
In article [EMAIL PROTECTED], Graciliano M. P. [EMAIL PROTECTED] wrote: Is not the 1st time that I receive a FAIL report from CPAN telling that is not possible to find module X at @INC, saying to add the PREREQ_PM at MakeFile.PL. Well, I always put the PREREQ_PM at MakeFile.PL. So, some testers are ignoring this informations in the MakeFile and producing error reports! It's not that the testers ignore it. they don't even look at it. Most of CPAN Testers is automated, so it just happens and the responsible person doesn't monitor it. Add to that various versions of CPANPLUS which have various bugs, and you get a lot of bad reports. It seems like an easy problem to fix: either make CPANPLUS work right or don't use it for automated testing. If you get a report that says there is a missing prerequisite, verify that it isn't in PREREQ_PM before you send the report. Still, no one has cared to do that. I haven't had anyone remove these bogus failures from the database either. -- brian d foy, [EMAIL PROTECTED]
Re: CPAN question
[[ This message was both posted and mailed: see the To, Cc, and Newsgroups headers for details. ]] In article [EMAIL PROTECTED], Sean Quinlan [EMAIL PROTECTED] wrote: On Wed, 2004-11-10 at 19:35, _brian_d_foy wrote: You can mark distributions as developer releases, upload as appropriate, and delete distributions when you don't need them any more. :) Thanks, sounds perfect! I looked around PAUSE though and couldn't find anything that seemed to allow them to be marked as developer releases. just add an underscore and digit at the end of the version number. $VERSION = 0.50_01; # for instance -- brian d foy, [EMAIL PROTECTED]
Re: CPAN question
[[ This message was both posted and mailed: see the To, Cc, and Newsgroups headers for details. ]] In article [EMAIL PROTECTED], Sean Quinlan [EMAIL PROTECTED] wrote: My impulse is to regularly update the modules on CPAN, at least until we get a semi-functional beta in place. But I'm apprehensive that using CPAN like CVS might annoy some of the maintainers. :) You can mark distributions as developer releases, upload as appropriate, and delete distributions when you don't need them any more. :) -- brian d foy, [EMAIL PROTECTED]
Re: cpan-testers rant
In article [EMAIL PROTECTED], David Coppit [EMAIL PROTECTED] wrote: Can someone please tell me how to convince cpan-tester's automated testing to: - Not test unless required modules are installed. (Of *course* it fails if you don't have a required module installed.) it would be nice if some of the automated test set-ups were fixed. In some cases I think they must have different @INC paths for the perl they used to run the Makefile.PL and the one in the actual Makefile. I can't confirm this because those testers don't respond. -- brian d foy, [EMAIL PROTECTED]
Re: CAD::* namespace
[[ This message was both posted and mailed: see the To, Cc, and Newsgroups headers for details. ]] In article [EMAIL PROTECTED], Eric Wilhelm [EMAIL PROTECTED] wrote: I've got several modules under the CAD::* namespace, which I chose because there was an existing module CAD::ProEngineer. Why are they all filed under commercial software interfaces? I wouldn't worry too much about the category. I don't think too many people really care about them anymore. CAD::Calc, and CAD::Drawing have nothing to do with commercial software. I'm afraid that my namespace registration for CAD::Drawing was completely ignored. it might have fallen through the cracks. I found the original request and approved it. -- brian d foy, [EMAIL PROTECTED]
Re: Design philosophy (was Re: Module name: WWW-ISBNReference)
In article [EMAIL PROTECTED], Robert Rothenberg [EMAIL PROTECTED] wrote: On 7/25/2004 2:26 AM brian d foy wrote: On Sun, 25 Jul 2004, Robert Rothenberg wrote: I don't think it's appropriate to merge with Business::ISBN, which just deals with ISBN data. The isbnsearch system is a distributed, open-source isbn-lookup system for bibliographic data. Business::ISBN does much more than that. Why not put all the ISBN stuff in one place? Looking at the docs and source forge page, Business::ISBN seems to just deal with ISBN information. Have I missed something? One of my pet-peeves with many CPAN modules is that they try to be everything for everybody, which means they make it harder for developers to customize to their needs. it's not the ease of developers that concern me. the truly popular modules have been the ones that pull things together for the users, like DBI and LWP. -- brian d foy, [EMAIL PROTECTED]
Re: Module name: WWW-ISBNReference
In article [EMAIL PROTECTED], Robert Rothenberg [EMAIL PROTECTED] wrote: I am working on a module that can query isbnreference.org for information about a particular book. have you thought about working with Ed Summers to put that into Business::ISBN ? -- brian d foy, [EMAIL PROTECTED]
Re: Module name? CPAN::Distribution::Depends
In article [EMAIL PROTECTED], Robert Rothenberg [EMAIL PROTECTED] 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. This should be able to do the same thing for non-CPAN distributions too, and maybe even distributions that aren't modules. :) -- brian d foy, [EMAIL PROTECTED]
Re: Perlforge? (was: Re: CPAN Rating)
In article [EMAIL PROTECTED], Mark Stosberg [EMAIL PROTECTED] wrote: One benefit I see of a extra forges like rubyforge is decentralization. Right now open source has a huge dependency on SourceForge. Indeed. SourceForge's services and uptimes have been slowly degrading, and lately I have seriously considered not using it anymore. A programmatic interface would be really nice, but SourceForge is never going to get around to it. -- brian d foy, [EMAIL PROTECTED]
Re: Application framework namespaces
In article [EMAIL PROTECTED], Mark Stosberg [EMAIL PROTECTED] wrote: On Fri, May 14, 2004 at 03:17:50PM -0400, _brian_d_foy wrote: In article [EMAIL PROTECTED], Michael A Nachbaur [EMAIL PROTECTED] wrote: I'd rather see top-level namespaces for complete applications. I don't think the App::* adds any information. :) I would imagine that you meant to qualify this statement with an assumption that the applications have decently unique names, i didn't really care to do that, but you would have to anyway to escape the wrath of the PAUSE and CPAN admins. -- brian d foy, [EMAIL PROTECTED]
Re: getting rid of some unmaintained modules
In article [EMAIL PROTECTED], Sherzod Ruzmetov [EMAIL PROTECTED] wrote: Instead of removing any modules, edit the docs of the library stating the modules are obsolete, unfinished, broken etc. If there are any other modules that you know of to be used as an alternative, list them, but keep the latest revisions of your libraries on CPAN. I agree. Someone might come along, find them useful, and take them over. Maybe, however, we can flag distributions as abandoned and publish that list. That might give some modules the attention they need, or find a good home for them. -- brian d foy, [EMAIL PROTECTED]
Re: fix bad upload?
In article [EMAIL PROTECTED], Tim Harsch [EMAIL PROTECTED] wrote: I forgot to include Makefile.PL in my distribution. Would prefer to just replace the offending upload, rather than up the version number and start again. Would that be the best way? you can't upload a file of the same name again, so you would have to upload the latest distribution with a different name, then replace the old one. i think it's easier just to bump the version number though, and that's what i do when i mess up like that. -- brian d foy, [EMAIL PROTECTED]
Re: CGI::Uploader (was: CGI::FileManager)
In article [EMAIL PROTECTED], Austin Schutz [EMAIL PROTECTED] wrote: It would be nice if there were some way to take over management of the module from the current owner. If they aren't responsive, there ought to be some mechanism for doing it without their input. if you need to take over a module, post to [EMAIL PROTECTED] . I or another PAUSE admin can help you. We will try to reach the original module owner in any way we can first, and give them ample time to reply (in case they are on vacation, and so on). This is something we do very rarely, and in this case it sounds appropriate. -- brian d foy, [EMAIL PROTECTED]
Re: Taking Over Maintenance of a CPAN Module
In article [EMAIL PROTECTED], James E Keenan [EMAIL PROTECTED] wrote: I know that we've had a lot of discussion on this list about taking over maintenance of apparently abandoned modules ... If you cannot reach the author, post to this or the perl modules list, and one of the PAUSE admins will try to contact the author and make a public announcement about the proposed transfer. If the author does not surface after a couple of weeks (remember, they may be on holiday or some such), a PAUSE admin can transfer the module. -- brian d foy, [EMAIL PROTECTED]
