what to do with dead camels ?
There are a few modules on CPAN that seem to be dead. Without pointing fingers (to myself :-), let's say there is a module called Dead::Camel someone started to develop, uploaded to CPAN but it never reached any form of usable version or for some other reason it is unusable today. Eliminating these modules from CPAN might do a little good for the world. So what should be the course of action with such a module ? If I encounter such a module what should I suggest to the author ? Should one just remove all the versions of that module ? I thought of uploading (and if it is someone else's module than asking the developer to upload) a newer version of the module that at least says that this module is not for use and other people are welcome to overtake the namespace. What do other module authors suggest ? BTW I think this list should be mentioned at least in http://www.cpan.org/modules/04pause.html but maybe also in http://cpan.org/misc/cpan-faq.html What do you think ? Gabor
Pod::Index and podindex released
Hi, while Yehuda Berlinger - the author of this module - has already mentioned it here I'd like to draw your attention to this module again and ask for your help.[1] Yehuda took a script called perlindex (from CPAN) and based on that created a module and a script that is capable to index all the POD files installed in your perl installation and then it gives you a way to search the PODs from the command line. Because of some minor administrative issue (the same name has been registered by someone but never uploaded) we could not upload it to CPAN yet. You can download the latest version from http://www.pti.co.il/download/ My assumption is that most of you don't really need such an indexed POD database as you are very familiar with the documentation or how to find something there. I guess it will be much more useful for beginners but you can still help in 1) suggesting some other name if you think we should not wait for the person who registered this name. 2) Check it out, give feedback, bug reports and ideas how to progress or just telling us its plain stupid and no one needs that so we won't invest more energy. As usual. No Warranty. Use at your own risk. Gabor [1] Yehuda is the developer while I am the marketing manager of this module :-)
Re: Application mechanizing
The Win32:: namspace is also quite established to applications specific to that platform so if the underlying application is Windows specific I think using Win32:: would be a good idea. I'd understand more something like Win32::Automate::app or Win32::Drive::app. less than 2c. Gabor
getting rid of some unmaintained modules
I have released 3 modules to CPAN earlier, when I thought it is fun to have some modules up there. Actually they don't do much there so I'd like to get rid of them. Two of them have never really worked so I can safely assume no one uses them. I think I can just delete all of their copies from CPAN, right ? Regarding the 3rd one Array::Unique, I get once in a while some indication that people are trying it and maybe even using it. Even though I don't think that in its current state it is worth using it. (I even say so in the docs.) http://search.cpan.org/dist/Array-Unique/ Is there anyone who would like to take it over and make something more useful out of it ? If not, what shall I do if I'd like to get rid of it. Shall I remove all of its copies from CPAN or shall leave the latest version and put an empty module with the same name saying it will be removed soon ? regards Gabor
CGI::FileManager
I am looking for a module that can be used as part of a web based application which requires management of a (partial) file system. If there is no such module I wonder if it would be interesting to add to CPAN ? In our current state operations required are - upload new file (with a customised hook to validate it before [1]) - download file - rename - delete - merge two files (in a customised way so that will probably require some hook or sub classing the module. [1]) - edit file (in a customised way so this requires a hook too [1]) [1] We are dealing with XML files so we'll have to edit those in some way that makes it simple for the user. I saw Apache::FileManager but that is mod_perl dependent and this application should not be. For uploading a file I could use CGI::Upload. So my questions are: - Is there such a module that someone could recommend ? - If there is no such module would a generic FileManager module using CGI be interesting on CPAN ? - What name ? CGI::FileManager ? - What else should such a module include ? Gabor
Re: getting rid of some unmaintained modules
On Mon, 10 May 2004, Christopher Hicks wrote: On Fri, 7 May 2004, Mark Stosberg wrote: I believe even if you delete them all from your directory, everything ever uploaded is still available on 'backpan': Actually I have just noticed that link on the home page of every author on search cpan that leads directly to the relevant backpan home directory. So while I cannot fully eliminite further embarrasment by displaying my broken modules on every CPAN at least they can be pushed to the back of our common memory. thanks for your comments Gabor
mailing list or web site for individual module
Is there some standard and machine readable way to describe where is the mailing list and home page of a module ? Maybe a field in META.yml with this information ? Then someone could collect this information and present on a web page (maybe it could be included as a link on search.cpan.org ) Gabor
Re: how to add the license field to META.yml ?
On Tue, 15 Jun 2004, [iso-8859-1] Sébastien Aperghis-Tramoni wrote: Use Module::Build to create your distribution, as it supports the license field of META.yml, and provide the classical Makefile.PL from ExtUtils::MakeMaker so that users don't need to install Module::Build just to install your module. Yes, that's what I did. Thanks. Gabor
Re: Ratings and Reviews ne Modules
On Thu, 22 Jul 2004, Randy W. Sims wrote: Agreed. Reviews as modules is not the best solution. CPAN does one thing and does it well. Adding reviews as modules is likely to cause more problems that it solves. Do we really need reviews ? I am afraid not many people will take the time to do a deep analyzis of a module. On the other hand, I guess, they would be ready to give their short opinion or ideas on how to use the module, or which other module to use instead. For part of this cpanratings fits well, maybe it needs improvements but that's one direction. There are two other options for some improvement: What about creating an annotation system similar to what PHP has on its documentation (see www.php.net ) ? It might be part of the rating system or might be separate. What about a web based discussion board that is module specific ? Easy to search, categorized by modules, easy to post - no need to subscribe to a zillion mailing lists. Gabor
Re: cpan-testers rant
On Fri, 17 Sep 2004, David Coppit wrote: Actually, in the last couple of days I've gotten email from something that claims to be an automated testing service. (Sorry, but I deleted the email.) Interestingly I have just tried to install grepmail using CPANPLUS and it sais No such module: grepmail m grepmail came up with 1 Test::ConfigureGrepmail but then trying to install that module first asks me all kinds of standard questions (where to install and where is my gzip) and then fails. Overall, I'm just frustrated. I really do work hard on getting good releases, and I give very detailed instructions on (1) installing prerequisites, and (2) giving me enough info to debug test failures. But these folks seem to think that if it doesn't install automatically, it must be a module bug. I find it very hard to understand why can't one install a module automatically but that might be only me. I would be very interested understanding what are the reasons for grepmail not to install automatically ? Gabor
Re: Old CPAN modules not being purged by authors
On Wed, 24 Nov 2004, Tim Bunce wrote: I suspect some authors forget about purging because there's nothing to remind them about it (I know I'm guilty of that). Some authors might not be aware of purging at all. When an author uploads to PAUSE (or clicks the button to take ownership of a previous ftp upload) PAUSE currently returns them to the same page with with some words added to the top about how to track progress. If, instead, it took them to the Delete Modules page[1] (with the same words added to the top) it would act as a clear reminder that uploads should be balanced by purging of old versions. and/or it might help if the e-mails the author gets when s/he uploads a new version would include a reminder to purge the old version with a link to the [1] page. Gabor
MakeMaker META.yml and license
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 ? Does anyone know when will MM support it ? Gabor
CPAN::Forum
Hi fellow module-authors, I have been working on this for more than half a year on and off. (mostly off) Finally I think it has the bare minimum to open the service. CPAN::Forum is a web forum to discuss CPAN modules. One of the objectives is to let people easily monitor discussions on several modules of their interest without subscribing to many mailing lists. It will also help lots of module authors for modules that do not have a mailing list (I guess about 95% of all the modules on CPAN) to provide support. If you are interested you can check it out at http://www.cpanforum.com/ So if you are a module author but your module does not have its own mailing list or web forum yet, you can make use of CPAN::Forum Let your users know that your module can be discussed at http://www.cpanforum.com/dist/Distro-Name and they will be directed to the sub forum of your distribution. You can also subscribe to get e-mail notification whenever someone posts to this distribution without visiting the site. I'd appreciate your feedback either here or better yet on http://www.cpanforum.com/dist/CPAN-Forum regards Gabor
Re: CPAN::Forum
On Wed, 2 Feb 2005, Johan Vromans wrote: Gabor Szabo [EMAIL PROTECTED] writes: http://www.cpanforum.com/dist/CPAN-Forum May I suggest to reserve/use/allow CPAN ids for nicknames? I don't think I can do that. For one thing I can't make sure that a future PAUSE id will not be already taken on the forum. How would you implement it and if someone comes along and claims he is DCONWAY how can I make sure he really is DCONWAY from PAUSE ? Gabor
Re: CPAN::Forum
On Wed, 2 Feb 2005, Nicholas Clark wrote: The same hack as rt.cpan.org uses - attempt a login on pause.cpan.org using the ID and password provided. If PAUSE accepts it, then you know it's the real thing. That would mean my server if cracked could be used to collect PAUSE passwords. I am not sure I'd like to have that responsibility. I am thinking of allowing users to use a screen-name and if I manage to authenticate that you are a PAUSE user (using the suggested @cpan.org e-mail trick) then you will be able to uese the PAUSE::yourname screen name. Sounds like overcomlicating things. But it is nearly 3 am. Gabor
Re: CPAN::Forum
On Fri, 4 Feb 2005, Fergal Daly wrote: There are two useful things that could come from having some PAUSE interaction As an author of several modules, I'd like to be able to tick a box that says monitor all forums for my modules Also, it would be nice if users can see that the author is monitoring a module, it saves having to post a hey everybody I'm monitoring this module type of message for each one, Fergal The only problem I can see with this is that people would think the module author is NOT around if this sign is no up and I am sure some of the authors will prefer to monitor their modules using the RSS feed. Besides not having the module author monitoring the forum does not really mean one should not post a question. There might be lots of other people around who can answer that question. Gabor
Re: better SEE ALSO sections
Hi, plug http::/www.cpanforum.com while not a wiki tries (in the TODO list at least) answer some of what you are looking for. Specifically I though of setting up - with the help of the users - groups of moudules or categorizes from within th list of all the modules on CPAN and then allow discussion per such larger group. I think these groups could be overlapping as there are modules that will fit several categories. While it is not a wiki and does not allow co-editing of documents it can let you write articles comparing sets of similarly themed/purposed modules. Gabor
Re: Parse::Lex abandoned?
On Wed, 16 Mar 2005 09:46:05 -0500, Sean Quinlan [EMAIL PROTECTED] wrote: Speaking of mailing lists, is there a community listserv authors could use? I have mailing lists for a couple projects (currently getting dusty), but not everyone might have the option to set up their own mailing lists. And setting up a sourceforge project may be way over the top for many small modules. If there is not currently a freely available source, this is something I might be able to contribute to the community, at least for a large number of relatively low-traffic lists. selfish This more or less what CPAN::Forum is about. Though it is a web forum and not a mailing list but you do get announcements when someone posts to your module. http://www.cpanforum.com/ There are a number of features people requested on this list and elsewhere, that will make things easier for module authors. If you have time I'd appreciate some help with adding those features. /selfish Gabor
Re: Give up your modules!
Maybe if there was some alerting system 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 don't know. Gabor
Re: Give up your modules!
On 8/15/06, Sébastien Aperghis-Tramoni [EMAIL PROTECTED] wrote: Quoting Ovid: Said in another way, if you feel that there is a number of modules that need a new maintainer while bug are piling up, it's usually not because the author doesn't want to give the co-maintenance, but because nobody wants to deal with such unfun work. Creating a web site which shows the modules in dire need of maintenance is a good thing, but the next question is: how many people here will then accept to maintain such modules? (History has shown that this number is very low.) There were quite a number of times I wrote to module authors asking to help with their modules. In many cases I have not heard back from them. As I see most of the modules are usually maintained by one person. It might be better if we could encourage co-maintenance of modules. Even small ones. The infrastructure to allow other people to upload the same module is there. If there are two maintainers it is much morel ikely that when one of them gets busy or tired the other one can still carry on AND find a new co-developer/co-maintainer. I can only describe what I feel: Personally I would not like to pass maintainership to anyone as I am still in the phase of *I want to reinvent that wheel* but I would really like to get some help with both my modules and my applications. I am not sure what would be the a good way to encourage people to cooperate more. Gabor
Re: Give up your modules!
On 8/15/06, Ovid [EMAIL PROTECTED] wrote: - Original Message From: Jonathan Rockway [EMAIL PROTECTED] To: James E Keenan [EMAIL PROTECTED] Cc: module-authors@perl.org; Ovid [EMAIL PROTECTED] Sent: Tuesday, August 15, 2006 12:50:47 AM Subject: Re: Give up your modules! Is there software that needs to be written? I could write a small Catalyst application to handle this, if someone is willing to host it. I suspect this isn't what you were talking about, but we could also assign weights to various components: 1. The number of bug reports and their severity. 2. Number of days since last release. 3. The number of CPAN tester reports (total, separating test failures is useless since those are mostly a waste of time) 4. The number of other modules which have a dependency on the current module. Multiply each number by its weight and sum them. Skip if no bugs are in RT (or multiply the first result by the next 3?) I guess such thing should be part of CPANTS. Gabor
Re: Give up your modules!
On 8/15/06, Jonathan Rockway [EMAIL PROTECTED] wrote: Isn't CPANTS down indefinitely? It alive and kicking: http://cpants.perl.org/ and I think Thomas Klausner would be glad to see more people hacking on it. Gabor
Re: CPAN::Forum update rss feed per PAUSEID
On 8/29/06, Johan Vromans [EMAIL PROTECTED] wrote: In addition there is an RSS feed for every PAUSEID: http://www.cpanforum.com/rss/author/PAUSEID Just replace PAUSEID with yours Okay, call me stupid, but what should I do with this? When I feed http://www.cpanforum.com/rss/author/JV to firefox it offers to download a application/rss+xml file. I am not really sure but in the meantime I added another page where you can get a listing of all the posts related to any of your modules. I will soon link it from other pages but in general it looks like this: http://www.cpanforum.com/author/PAUSEID or in your case http://www.cpanforum.com/author/JV The point is that when you vist this page with Firefox you get the RSS sign in the location bar and clicking on it will let you add the rss feed to your Bookmarks Toolbar. Gabor
Re: CPAN::Forum update rss feed per PAUSEID
On 8/29/06, Éric Cholet [EMAIL PROTECTED] wrote: Le 29 août 06 à 17:08, Johan Vromans a écrit : Okay, call me stupid, but what should I do with this? When I feed http://www.cpanforum.com/rss/author/JV to firefox it offers to download a application/rss+xml file. Welcome to the RSS mime type can of worms. http://www.petefreitag.com/item/381.cfm Gabor
Re: CPAN::Forum update rss feed per PAUSEID
On 8/29/06, Jonathan Rockway [EMAIL PROTECTED] wrote: http://www.petefreitag.com/item/381.cfm Hacks like these are ruining the Internet. I am not sure it was aimed at me but I go defensive here. I have no written that, I have not even implemented it on CPAN::Forum. I just learned from it to use application/rss+xml and then sent it here as a form of explanation. Now what a waste of e-mail this was. Gabor
Re: Licenses in a commercial application
On 3/18/07, David Golden [EMAIL PROTECTED] wrote: You might find this open book helpful: http://www.oreilly.com/catalog/osfreesoft/book/ thanks 8. Aggregation of this Package with a commercial distribution is always permitted provided that the use of this Package is embedded; that is, when no overt attempt is made to make this Package's interfaces visible to the end user of the commercial distribution. Such use shall not be construed as a distribution of this Package. What does that mean that no overt attempt is made to make this Package's interfaces visible ? How can I make sure we are fulfilling this requirement? Quoting from that book: This Section 8 accordingly limits the generally free distribution of the source and executable codes under Section 1 and 4 respectively when that distribution is part of a commercial aggregate with the Package. In those situations, the Package may be utilized as part of the commercial program, but its interfaces (and, correspondingly, the ability to write new scripts in Perl) must be blocked from the end user. This section is presumably included to prevent commercial distributions of programs written in Perl from competing with the parallel open source distributions of Perl that are intended to encourage innovation and contributions to Perl itself. That would mean ccperl and all the other vendor supplied perls were actually violating with this section. If package a script with PAR including everything even perl itself then after it is installed it allows writing scripts on this perl. If you create a compiled distribution based on perl and a bunch of CPAN packages and optionally some propriatery packages, is this then in violation of that section? I personally don't see what's the point behind hiding this version of perl. Gabor
In which linux distribution is my module available
Hi, 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/ Gabor http://www.pti.co.il/
Re: In which linux distribution is my module available
On 5/4/07, Johan Vromans [EMAIL PROTECTED] wrote: Gabor Szabo [EMAIL PROTECTED] writes: A bit more work on it and now there is a report for each module author as well. http://www.szabgab.com/distributions/ Interesting numbers, but I have some problems interpreting the report. First, what do you mean by CPAN Modules in Distributions. Modules that are installed with a vanilla install? Modules that can be installed on demand? I am not sure. In the longer term I would like to provide the list of modules that can be installed by the standard packaging tool of each distribution on demand. As I am a bit more familiar with Ubuntu (and thus Debian) I plan to provide the list of modules that can be installed with apt-get using the standard *supported* repositories showing which module is coming from which repository. So in Ubuntu that probably only means main while universe and backports will be also shown separately. Some more explanation why: http://www.szabgab.com/blog/2007/04/1177742133.html http://www.szabgab.com/blog/2007/05/1178269908.html For example, according to the report, Getopt::Long is only available in FreeBSD but I'm pretty sure it is installed in all other distros as well. In addition, after I generated and announced the initial report I stated to look into how the data is fetched (which is done by Module::Packaged::Generate from Leon) and found out that the data collector of Mandriva is dead and Fedora actually means FC2. So since then I patched the module a bit and started to add more data sources. Specifically Debian was split into stable/unstable/testing, Ubuntu was added though it is very strange that there are only 75 modules in the latest version of Ubuntu and ActivePerl was also added with ~ 7000 modules! Still I would appreciate your help in both finding the sources and interpreting the meaning of the results. Particularly explaining how the various packaging systems and distributions work. Link to SVN on the report page itself: http://www.szabgab.com/distributions/ Puzzling... The Puzzle has more pieces in place now. I hope. Gabor -- Gabor Szabo http://www.szabgab.com/ Perl Training in Israel http://www.pti.co.il/
How to recognize modules that needs compilation?
Hi, I would like to create a list of modules that need compilations as opposed to those that are pure perl Is checking for a file with .xs .c or .h extension in the distribution the correct thing to do? Is there a better way to collect this information or is it alrady available somewhere? In addition I would located modules that have dependecies that are not available on CPAN. (e.g. most of the DBD::* modules are such but DBD::SQLite is not such a module as it includes all the C code of SQLite) Gabor
Re: How to recognize modules that needs compilation?
thanks for all the ideas. Gabor -- Gabor Szabo http://www.szabgab.com/ Perl Training in Israel http://www.pti.co.il/
CPAN::Porters
Hi, I would like to improve the coverage of the CPAN distributions available as binary packages in the various distributions. If you look at the stats I created recently ActiveState provide 5-7000 modules depending on platform while FreeBSD has only 2600, Debian only 1000 and others probably even fewer though the others distros are not represented well in the report. See http://www.szabgab.com/distributions/ While one can install many module quite easily using CPAN.pm or CPANPLUS I assume that as most of the people won't want to compile and install their own Apache or MySQL they won't want to install their CPAN modules from source either. Especially not those that need compilation and even less those that require external libraries. I assume this to be especially true for users who merely want to use an application written in Perl and requiring tens of modules. So I would like to somehow encourage people to add more modules to the various distros. I would like to get your help for this. As a minimum I think we need a document describing the process of adding a module to the various distros. We could also create some guide lines how to prioritize addition of modules. When to upgrade a module? It might be also good to have a mailing list where all these people could discuss the issues they are facing. Is there an existing mailing list or shall we setup for this yet another mailing list? I have started to write up something regarding this http://svn1.hostlocal.com/szabgab/trunk/CPAN-Porters/ What do you think? Gabor -- Gabor Szabo http://www.szabgab.com/ Perl Training in Israel http://www.pti.co.il/
Add tags to CPAN modules via CPAN::Forum
Hi, as I have written on use.perl.org already I have added a way to tag the CPAN modules via CPAN::Forum http://www.cpanforum.com/ Soon I'll start to provide a downloadable version of this information to be integrated with the search engines. To see the already existing tags visit http://www.cpanforum.com/tags/ Soon I'll provide a way to connect the username on CPAN::Forum with the PAUSEID so the tags added by module authors can have a higher weight in the search results. So go tag a module today. Regards Gabor -- Gabor Szabo http://www.szabgab.com/ Perl Training in Israel http://www.pti.co.il/
Re: CPAN security
For that reason too I prefer to use only modules that come with my operating system. Of course it has very limited number of CPAN modules ( http://www.szabgab.com/distributions/ ) and even those can be out of date to my purposes so in many cases I install them from CPAN. For that one might consider setting up a separate account on the system and setting PERL5LIB=/home/perl/perl5lib/lib in the environment and makepl_arg [PREFIX=/home/perl/perl5lib LIB=/home/perl/perl5lib/lib] mbuildpl_arg [--install_base /home/perl/perl5lib --install_path lib=/home/perl/perl5lib/lib] in CPAN::MyConfig.pm This will reduce the install time issues to that account - annoying but limited. In addition one might consider installing modules only after a reasonable time (M days) they are on CPAN and/or after having N successful test reports on http://cpantesters.perl.org/ These precautions might help reduce the security issues. Of course this still falls short of actually reading the code AND understanding it :-) Anyway this thread just gave me another reason to push my ideal of having more modules distributed by the various OS-es and other Perl distributions. http://search.cpan.org/dist/CPAN-Porters Gabor -- Gabor Szabo http://www.szabgab.com/ Perl Training in Israel http://www.pti.co.il/
Re: Maintenance of IO::Socket::INET6 - http://search.cpan.org/dist/IO-Socket-INET6/
On Feb 3, 2008 12:01 PM, Shlomi Fish [EMAIL PROTECTED] wrote: On Feb 2, 2008 2:14 PM, Nicholas Clark [EMAIL PROTECTED] wrote: On Fri, Feb 01, 2008 at 08:18:21PM +0200, Shlomi Fish wrote: Due to the fact I did not hear from the original author for 2 weeks, I'd like to ask the CPAN admins to give me (SHLOMIF on the CPAN) a co-maintainer status so I can upload my modifications (and future ones) as a new distribution. Some people go on holiday for more than 2 weeks. And some people go on holiday for more than that. The question is: how long should we wait? There wasn't a new release of IO::Socket::INET6 for over three years, and it has three pending bug reports. This probably indicates that the author is missing-in-action. Instead of this infighting why not just upload a development version of the module with something like this in the pod: This is an unnofficial version of module X::Y::Z till the original module author reappears or till I get official maintainership of the the module. Send another nice(!) letter to the author making it clear that you will be happy if he continued the maintenance of the module or if he passed it to you. Then wait for another few weeks before asking the CPAN maintainers again. In the meantime both you and the users can already use your not official and development versions of the module. Gabor
Re: Maintenance of IO::Socket::INET6 -http://search.cpan.org/dist/IO-Socket-INET6/
On Feb 5, 2008 12:55 AM, Rafael Martinez Torres [EMAIL PROTECTED] wrote: First at all, I want to apologize. I'm the original maintainer of IO::SOcket::INET6, but three years ago I'm not in charge of that. No need for apology. You are a volunteer just as the rest of us. The [EMAIL PROTECTED] is barely attended, because if has tons of SPAM, and the mail server does not detect it. Write me back into [EMAIL PROTECTED] in case of trouble. Now it will be harvested by the spam-bots and you will get tons of spam to this address too :-) Shlomi, please... As Gabor said, I'm afraid I can no longer to maitain this module, at least on medium term. So, tell me what can I do to delegate this module maintenance to you. As a transient solution, just reply me with a private mail to [EMAIL PROTECTED], and I will tell you the paswords and the CPAN author: MONDEJAR . Then, we can try to pass you the module's main maintenance. I don't know if CPAN can enable a module to be maintained by several authors, as sourceforge does. If not, module will pass to you. I don't think giving out passwords is a good idea. You can just login to PAUSE and set SHLOMIF as a co-maintainer of all the modules in the package. Then he can upload to CPAN and be index. regards Gabor
uniform version numbers for CPAN modules
Hi, I know Perl is all about diversity but I wonder if requiring a uniform way of providing version numbers of modules on CPAN would be too much of restriction on the freedom of module authors? I think it would make life easier for tool authors (PAUSE/CPAN.pm/CPANPLUS etc) and downstream distro packagers (e.g. Debian and co.) As far as I can tell there is already an almost universally accepted format of \d+\.\d\d for released versions and \d+\.\d\d_\d\d for development versions. Are there any compelling reasons to keep allowing any type of version numbers? Can the above be officially blessed - or agreed upon - and maybe enforced on some level? e.g. not indexing any module that does not have a version in the given format? Gabor
license in META.yml
As I am usually using Module::Build I did not know that a recent version of MakeMaker has started to support the LICENSE parameter and will include it in the automatically created META.yml. That in turn will increase your kwalitee metric In addition it is also very useful as it show up on the results page of search.cpan.org and is easily machine readable. You only need to add LICENSE = 'perl', to Makefile.PL as it can be seen here: http://search.cpan.org/src/PETDANCE/ack-1.78/Makefile.PL Gabor
Re: license in META.yml
On Mon, Mar 24, 2008 at 11:30 PM, David Landgren [EMAIL PROTECTED] wrote: Gabor Szabo wrote: As I am usually using Module::Build I did not know that a recent version of MakeMaker has started to support the LICENSE parameter and will include it in the automatically created META.yml. That has been the case for a couple of years or so. I think it was first introduced in 6.30. Now are you telling me... :-) and I have been giving the lack of LICENSE support of MakeMaker as the excuse why so many modules have their Lincense set to Unknown on search.cpan.org.[1] Then why are there still 9920 Distributions failing 'metayml_has_license' of CPANTS? Is that so unimportant or are the module author unaware of the way they can add it. It would be interesting to see how many of the modules with a recent (in the last 12 months) have their license field missing. Gabor [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. While they don't specifically use META.yml it is certainly one of the places where the license information should be.
Re: license in META.yml
On Tue, Apr 1, 2008 at 3:42 PM, Ricardo SIGNES [EMAIL PROTECTED] wrote: * 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. Have you been sitting in a time machine lately? now if someone could explain me why did search.cpan put the Software::License::Mozilla under documentation and not with the rest of the files... Gabor
How to declare dependency on other modules?
Hi, we have been discussing with Domm how CPANTS should check if a distribution declares each of its prerequisites correctly which brought us to the the point that we have a problem. Let's focus for now only on dependencies on other CPAN modules and not on external libraries. 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? The former is lots of work on my side but I think that is the more correct way to do it. If I only require Tk then one day Tk might be split in two distros Tk and Tk::Extra, moving some of the widgets to the extra distro. This will break my modules dependency declaration. What do you think? I have started to outline the recommended way of doing this here: http://www.perlfoundation.org/perl5/index.cgi?cpan_packaging but of course your input is highly appreciated. regards Gabor
Re: Machine-Manipulatable Arguments for Module::Build
On Fri, Apr 11, 2008 at 2:59 PM, Shlomi Fish [EMAIL PROTECTED] wrote: I hope it's not much of a flamewar so far, but it sure seems to have escalated into a minor one. You are a Nazi![1] - oops! Regards, Shlomi Fish [1] - http://en.wikipedia.org/wiki/Godwin's_law I am really sick of this game with Godwin's law. I think calling someone Nazi is offending even if its in quotes and is places in such context. It is offending even if the person to whom you write does not get offended. I personally feel offended every time someone starts to call nazi to a fellow mailing listers. So I'd highly appreciate if you stopped it. Gabor
Re: How to declare dependency on other modules?
On Sat, Apr 12, 2008 at 1:46 AM, David Cantrell [EMAIL PROTECTED] wrote: On Fri, Apr 11, 2008 at 06:39:21PM -0400, Ricardo SIGNES wrote: 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. Catalyst is an excellent example. I'm sure it has gone through at least one fairly major re-organisation of its distributions at some point. So for what is Catalyst a good example? If I understand RJBS said it is a good example for a distro that *does not* get split up while from David I understood it *did*. So am I just falling in the crack between US and UK English or did you really say the opposite? Gabor
Re: shipping extra files in a dist?
On Fri, Apr 25, 2008 at 6:43 PM, Aristotle Pagaltzis [EMAIL PROTECTED] wrote: * Jerome Quelin [EMAIL PROTECTED] [2008-04-25 09:40]: 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. Do they need to be physical files or do you just need the data to tag along somewhere? If you just need the data the, you could have a helper script that takes the files in the source tree and sticks them at the bottom of your main module after __DATA__, or in a My::App::Data module after __DATA__, or as string constants, possibly uuencoded (cf. `perldoc pack`), etc. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/ I just wanted to ask the same question for a Gtk2 application I am writing. It has an xml file generated by Glade and currently during perl Makefile.PL I generate a .pm module from the xml file with a single function that returns the content of the xml file. It works, but I think including the content of these extra files in .pm files is not the right direction. I think the Perl community should come up with some more-or-less standard solution supported by Module::Build and MakeMaker that also plays well with the downstream distributors. Maybe there should be an extra/ directory defined by perl where each module can have its own directory to put its extra files to. regards Gabor -- Gabor Szabo http://www.szabgab.com/
Re: Find A Tester
On Tue, May 27, 2008 at 4:40 PM, Barbie [EMAIL PROTECTED] wrote: As this has started cropping up a little more, now that the cpan-testers no longer sends the reports out, and prompted by Eric's post yesterday, I've added a little form to the CPAN Testers Statistics site [1]. [1] http://perl.grango.org Maybe this link should be included in the report messages or maybe in the message PAUSE sends to the author. Can this, or rather something better written added to the message PAUSE sends out? == Thanks for uploading this module. It has been indexed so hordes of bots will download it and try to execute the test suit. You might get reports about your module being broken or you might find such reports on http://cpantesters.perl.org/.. (link to the right page, if possible) If something is not clear you can try to find answers on the CPAN Testesrs wiki at http://cpantest.grango.org/ If things are still not clear you can always ask on the module-authors mailing list http://lists.cpan.org/showlist.cgi?name=module-authors == -- Gabor Szabo http://szabgab.com/blog.html Test Automation Tips http://szabgab.com/test_automation_tips.html
Re: How to challenge a cpan-testers test result?
On Tue, May 27, 2008 at 7:25 PM, David Golden [EMAIL PROTECTED] wrote: And I would suggest that anyone you think should need to know nothing about the CPAN ecosystem shouldn't be installing modules via CPAN or CPANPLUS anyway, but should be using a packaged perl that can provide more robust dependency resolution via ppm, rpm, deb or whatever anyway. I agree with notion and I think this is one of the main reasons to what I am trying to achive with having lot of CPAN modules in Debian/Fedora/etc... The problem is that while the Linux distribution maintainers advocate that everything should be installed via their own package management system we aka. The Perl Community advocate the use of CPAN(PLUS)?. One of the reasons is that in almost any application you write you'll use modules that are not in the package management system. So until we solve that we have to teach our users how to install modules using CPAN. Even after we manage to get 50% of CPAN in Debian or Fedora it will take ages till most of the places start to use these distributions and these uncaring module authors keep releasing all kinds of useful modules that others start using in various application so people will need to install them using CPAN(+-). I am sure this will be a difficult catch-up game. So I am not sure. There are lots of system administrators who need to install applications that rely on modules from CPAN. Many of those applications are not in the Linux (or whatever else) distro they happen to use so they need to install all those CPAN modules. I don't expect any of them to learn how to install CPAN modules and the CPAN ecosystem. (OK, maybe I should by I know the majority does not have the interest or time) Should the applications come with all the dependencies? There are a few examples such as Krang and Smolder. Should the applications come in binary format (.deb, .rpm)? This will be to a restricted number of platforms as the developers don't have the expertise or the hardware or the time to build all the versions. And then we loose all the nice test reports... regards Gabor -- Gabor Szabo http://szabgab.com/blog.html Test Automation Tips http://szabgab.com/test_automation_tips.html
Re: How to get a cpan user to upgrade?
On Tue, May 27, 2008 at 8:49 PM, Eric Wilhelm [EMAIL PROTECTED] wrote: Yes, there's an easy fix to force a toolchain upgrade and solve the supposed bootstrapping problem. No, nobody seems to think that gutting the 02packages.details.txt.gz file is a good idea. I must have missed the part, but why do you dislike 02packages.details.txt.gz so much ? Gabor -- Gabor Szabo http://szabgab.com/blog.html Test Automation Tips http://szabgab.com/test_automation_tips.html
Re: Tracking down the reason test failure
On Wed, May 28, 2008 at 5:40 AM, David Golden [EMAIL PROTECTED] wrote:
You hard-coded a path to perl in t/Run.pm:
my @cmd = qw{/usr/bin/perl -Ilib -MPod::HtmlEasy -e};
You should use $^X instead so that you're using the same perl that is
running your tests.
Any idea how to locate such issues automatically without false positives?
PPI?
A simple grep?
Are there use cases where one should have /usr/bin/perl or /usr/local/bin/perl
in the code anywhere? In Makefile.PL ?
regards
Gabor
--
Gabor Szabo http://szabgab.com/blog.html
Test Automation Tips http://szabgab.com/test_automation_tips.html
Licenses of CPAN modules
I know most of you don't want to think about this or don't care at all but others do. So I'd like to clean things up a bit in the way CPAN modules are licensed. Let's think about it as a necessary evil... While I respect the right of everyone writing whatever they want as license I would like to make sure that those who don't know or don't care can have an easy way to say that they distribute their code under license X. I would like this to be correct for the major values of X: the Perl license Artistic 2.0 Artistic 1.0 GPL Others can be added too and that's actually one of my questions here. Which license should be added? Thomas and I would like CPANTS to be able to check that modules declare about their license in a way acceptable by corporations, lawyers and even Linux distributions. So here are some items that should be checked. I am thinking aloud, please comment: - CPAN distributions should have a LICEN[CS]E file with the exact text of the license in it - Each distributed files should have a short version of the license. Maybe this would only mean the .pm and .pl files, maybe only the .pm files, I am not sure - 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) - Preferably every file in the distro should be under the same license, The LICEN[CS]E file should hold the text of this license and META.yml should declare the same license. When there are portions of the distro under different licenses, (e.g. I think DBD::SQLite) there should be a clear indication of this (how? where?) I think TPF should get legal advice on how and where this information should be written? TPF should also get legal advice on what should we do with our current text on the existing distros? Changing the license of a module could be an issue as well. Then TPF should publish some of the recommended options. BTW There are several tools out there: 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? Software::LicenseUtils in the same distro can help recognizing licenses within the pod. Case study: 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. I don't know if that matters for the legal departments - TPF should find that out - and then make sure we are checking the same thing legals will. comments? regards Gabor -- Gabor Szabo http://szabgab.com/blog.html Test Automation Tips http://szabgab.com/test_automation_tips.html
New CPANTS metrics
Two days ago or so I posted a blog entry about the new CPANTS metrics. http://szabgab.com/blog/2008/06/1212827982.html I am glad that already there are some comments about them even if both chromatic and Andy Lester are well, slightly against them and even Ovid did not like the Test::NoWarnings metric. http://use.perl.org/~chromatic/journal/36627 I know they all are authorities in matters of quality but I hope at some point I might be able to either convince them or learn from them how to improve these metrics. Anyway, shall we leave all the fun to the use.perl.org readers only? I am sending this to both the module-authors list so you can be aware of the new metrics and the perl-qa list as they might have a few words as well regarding kwalitee. BTW if you go to CPANTS http://cpants.perl.org/ you will see that all the new metrics are marked as experimental and as such by default they are not supposed to be displayed. Also if you as a module author are interested in what's the status of your module in downstream distros (well, currently only debian) then you can go to CPANTS and check it out. There are two issues regarding the criticism: 1) I did not find any mention of any new metric that would be good. I'd be really glad to hear ideas of what could be a good metric? 2) True, it would be great if more of the module authors knew about CPANTS and cared. I agree so how could we let them know about it besides posting on use.perl.org and on this mailing list? Maybe http://perlbuzz.com/ ? Any other ideas? regards Gabor -- Gabor Szabo http://szabgab.com/blog.html Test Automation Tips http://szabgab.com/test_automation_tips.html
Re: Fwd: New CPANTS metrics
On Tue, Jun 10, 2008 at 9:51 PM, Thomas Klausner [EMAIL PROTECTED] wrote: is_prereq is an optinal metric and thus does not count for the CPANTS game. And yes, Apps ususally won't get prerequed. Tough luck. Actually I'd love to be able to add some way to measure which module is used OUTSIDE of CPAN. Fetching data from sourceforge an alike. Sure it will be skewed as some modules are more likely be used in open source projects than others. Someone could also game it by starting tons of Sourceforge projects using his own module. One could also break in the CPANTS server and change the database to to show his module at a higher rank. I guess breaking in a bank pays better. (and isn't necessarily harder :-) Gabor
Re: Fwd: New CPANTS metrics
On Tue, Jun 10, 2008 at 10:21 PM, Eric Roode [EMAIL PROTECTED] wrote: extracts_nicely: How much of a problem is this, really? A lot of people hate tarballs/zip-files that spew their content into the current dir. Especially if the offending dists contains lots of files. Or a file with the same name as one you had in the dir... I can agree with that; I just question how much of a problem it is. I don't have stats but I'd like to believe that part of the problem went away because CPANTS pointed out the problem. The cpants.perl.org site claims that 524 distributions fail this test; however, at least one of those appears to be erroneous: My Config::Vars module does indeed come packaged as a tarball that unpacks into its own directory, yet it is listed as failing. So I guess: consider this a bug report. And perhaps there are other distros that do not really have this problem. thanks, if Thomas keeps his tuits low I'll try to check this but he is the ultimate gate and knowledge keeper. [...] use_strict: Misguided. use strict is a valuable tool for developers, but it is not necessary (or even desirable) in all circumstances. Huh? Do you us to head back to the funny times of Matts Script Archive? Well of course not. But use strict is simply a tool for helping developers write modules and programs more correctly. I guess it does show the end-user of a module that the module author is smart enough not to shoot himself in the foot. The module author might be smart enough without strict.pm too, but how can one tell? I guess that's the CPANTS logic. What if I have to go and change something in your module? I know I am not smart enough to work without the hand holding of use strict and use warnings. So I can quickly break the module. Maybe I won't even notice but someone who uses my version will start complaining. To you... I might be a bit more clever and add use strict and use warnings before I start changing your code. But what if you used symbolic refs in some areas? Now it won't compile and I have no clue in which area to disable strict. has_example: Possibly useful, but poorly implemented (or possibly poorly documented). Most modules that include examples do so in an Examples section of the POD, not in a separate file or directory. The has_example documentation implies that it'll only be satisfied by a separate file or directory. Can you back up the statement regarding Most modules .. do so in an Examples section? If yes, I'd love to integrate the code you have written to do so into CPANTS, to make it even better. I can't back it up statistically, only anecdotally: Many modules I've used have Examples sections in the POD. Very few have an Examples directory. (cpants.perl.org lists over 11,000 that do not meet this metric). Personally I never liked this metric either. Most of my modules fail on it but I think instead of adding empty eg/ directories I'll just live with the knowledge that for the time being my modules are not perfect. And one does not even need to look at them to know that :-) Gabor
Re: Fwd: New CPANTS metrics
On Tue, Jun 10, 2008 at 10:56 PM, Eric Roode [EMAIL PROTECTED] wrote: So I can quickly break the module. Maybe I won't even notice but someone who uses my version will start complaining. To you... I might be a bit more clever and add use strict and use warnings before I start changing your code. But what if you used symbolic refs in some areas? Now it won't compile and I have no clue in which area to disable strict. Then keep your grubby hands off my damn module! :-) You don't want to know how many times I find CPAN modules included in in-house applications. Sometimes renamed. Sometimes changed. You know, just a little bit... Gabor
Re: CPANTS has_test_pod* metrics
On Tue, Jun 10, 2008 at 9:33 PM, Ricardo SIGNES [EMAIL PROTECTED] wrote: * Dave Rolsky [EMAIL PROTECTED] [2008-06-10T13:23:09] The point is that you should ship a dist that is complete enough for an end-user to untar it, hack on the distro, run all the tests, and send you a patch. See, I think this is a lousy goal. More and more, I am not building my distribution tarballs like this: $ perl Makefile.PL $ make manifest make disttest make dist cpan-upload Dist.tgz When I do that, I have to do all kinds of obnoxious boring crap like include boilerplate POD, have a build tool that can run my release tests (but not let them get run by installing users), make sure that my changelog is up to date, update $VERSION in every module, and so on. It sucks. Sure, things like ShipIt and Module::Release and Perl::Version's perl-reversion help with a lot of this. They just don't do as much as I want. I want my build process to turn the code in my repository into a distribution for the CPAN. In other words, I supply: * the code and documentation specifically about that code * tests that all installers should run * tests that should be run before releasing * tests that I should run all the time when developing, but others shouldn't * a few pieces of metadata like license info and prereqs Then I get a tarball that has added a $VERSION to all my code, updated the POD =head1 VERSION section, made a Makefile.PL that includes the right prereqs, and made a MANIFEST that I know will be accurate. This saves me a huge amount of time. It's enormous. Further, the more work that I turn over to build automation, the more time I save as all of my dists can drop code they don't need. I'd love to see your environment and I think many of us could improve our module packaging system by looking at it. If it was even released to a repository of open source perl code [...] your points are valid and I'd be glad to make improvements once I understand how and have the tuits to do them. Gabor
Re: Debian patch
On Fri, Jun 20, 2008 at 5:13 AM, Ivan Wills [EMAIL PROTECTED] wrote: Hi, I noticed that my module SVG::Calendar has failed the kwalitee test has_no_patch_in_debian but does not tell me where to actually find that patch can any one tell me where to look? Also if the test knows that there is a patch (or patches) in Debian should it not report where they are to be found by default? It should but actually in this case there is another issue. This module also fails the distributed_by_debian that is, it is not distributed by Debian. So the other 3 new debian related metrics are actually irrelevant. We either have to turn them to green or maybe not display them at all. regards Gabor -- Gabor Szabo http://szabgab.com/blog.html Perl Training in Israel http://www.pti.co.il/ Test Automation Tips http://szabgab.com/test_automation_tips.html
Re: Begging for money - too tacky?
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. AFIK there are some other systems specific for donations. Maybe you should sign up with one of them and let people donate that way too. Do let us know how it works out :-) regards Gabor
Re: world writable directories
On Sat, Sep 27, 2008 at 9:29 PM, Shmuel Fomberg [EMAIL PROTECTED] wrote: So if you have a better permissions sets, and know how to create it on Windows, and made sure that the indexer agreed to index it, then please tell me. I don't know about the other parts but Andreas *is* the indexer ;-) Gabor
Re: The problem with auto-installing dependencies
On Tue, Sep 30, 2008 at 11:02 PM, Bill Ward [EMAIL PROTECTED] wrote: On Tue, Sep 30, 2008 at 12:46 PM, Ricardo SIGNES [EMAIL PROTECTED] wrote: * 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. It's a big part of my job to ensure that our tech stack at work doesn't get corrupted by bad code. On one hand if you trust and want module X then I would guess you don't have much choice but to trust and install all its dependencies so there is not much point in checking each module. On the other hand I wish we could use your findings either as CPANRATINGS or better yet through some not yet existing system where each one of us could say which authors do we trust or which specific modules do we trust and then also which users do we trust to use their opinion. The web of trust that has been discussed lately on several channels. After all you are doing some work we all wish we had time to do throughly when we decide on using a module. regards Gabor -- Gabor Szabo http://szabgab.com/blog.html Test Automation Tipshttp://szabgab.com/test_automation_tips.html
how can I building my own cpan server with old modules?
I don't want the latest and breakest of CPAN. Assuming I have a list of modules with the appropriate *old* version numbers that I know my application is working with. I would like to be able to point my *old* CPAN.pm to a CPAN mirror that carries exactly those modules with exactly those versions. So how can I build such a CPAN mirror along with its index files? regards Gabor
Re: how can I building my own cpan server with old modules?
On Fri, Oct 3, 2008 at 4:36 AM, brian d foy [EMAIL PROTECTED] wrote: In article [EMAIL PROTECTED], Gabor Szabo [EMAIL PROTECTED] wrote: So how can I build such a CPAN mirror along with its index files? Which part of the process are you hung up on? I am looking for the button to press. :-) The only part that's a pain is getting the list of modules from a distribution so you can feed it to CPAN::Mini::Inject. I haven't hooked up my BackPAN indexing stuff to that yet, but all the technology is there. I can prepare a file with Module::Name 3.12 Another::Module 7.28 actually I already have the list in my Build.PL and Makefile.PL Now I need a button (I'll settle with a command line tool) that I can press and that will build my precious CPAN micro that contains exactly those two modules and the index. Plus I'd like to get a report what else do I need with the possible version numbers. Gabor who is supposed to be on vacation right now
Re: how can I building my own cpan server with old modules?
On Fri, Oct 3, 2008 at 1:40 PM, brian d foy [EMAIL PROTECTED] wrote: In article [EMAIL PROTECTED], Gabor Szabo [EMAIL PROTECTED] wrote: Now I need a button (I'll settle with a command line tool) that I can press and that will build my precious CPAN micro that contains exactly those two modules and the index. MyCPAN::Indexer can do that, which means it is set up to be able to handle things like that but I haven't implemented this particular task. The latest MyCPAN stuff, which is my name for the BackPAN indexer, is now pluggable. You can tell it how to get a list of modules to process, how to process them, and how to write the report. If you look in the git archive, check out the test census example. For that, I have the indexer walk through distros, record the Test:: modules used, and then write a summary. That's the same task you have, but you want the modules in the dist (it finds that too) and a CPAN::Mini::Inject for each one. I just demonstrated this at Chciago.pm and have the screencast on Vimeo (and your exact use case came up too, but not while I was recording): http://vimeo.com/1808414 I have some other things on my plate right now, but I estimate this is about two days of work for me. How fast do you need this? If it's something that someone wants enough to pay some money, I could work on it during work hours. Thanks, great. I hope I'll be able to to look at all those once I am back from my vacation. I personally don't need it right now. The question came to me as IMHO this can be a solution for all those people who cannot upgrade their toolchain. They might not be able to install the latest and greatest from CPAN as those might need some brand new features of MB or EUMM but they can go back in time, have a custom built CPAN frozen in ancient times just as they need it with juts enough of the old stuff they need. Along the same lines I am not sure how difficult it would be to build a CPAN::Mini mirror that has the files as they were on any particular date in the past. So I would be able to say myminicpan --date 2006.06.27 and it would build a cpan mirror with all the files that were latest on CPAN on that day. If there was such an easy solution in place, module-authors would need to worry less about supporting old versions of perl or old versions of the toolchain. Users who are stuck with old toolchains or old perl could just build an old version of CPAN for themself. Plus I'd like to get a report what else do I need with the possible version numbers. You mean dependencies? That's easy to get it you want to beleive Makefile.PL or Build.PL, and slightly harder if you want the real answer. Yes dependencies but it is not enough to know which module I need, I'd also like to know what version did I possibly use back when I installed this application. Gabor
Add license to META.yml
The executive note: There is a license field in META.yml shipped with your distribution. On 24 March 2008 there were 9,920 distributions *without* such field. Today there are 10,235 such distributions. It is about 20 seconds to add this field to each one of your modules. as I described on my blog and it will be there the next time you release it. http://szabgab.com/blog/2008/10/1224314961.html So please take a short break from coding add the license field. Gabor
Integrating license related things of CPAN
I am trying to push forward simplifying and clarifying the licensing issues on CPAN. Here are a couple of issues I identified. I'd like to get your input on these issues hoping that we can have an agreement and then the people with the commit bits can implement them. 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. 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 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. If we can accept http://www.opensource.org/licenses as the official list of open source licenses the short names should be coordinated with them. 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. 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. 6) In this mail I have not yet dealt with how exactly the license is spelled out in the distribution (eg. LICENSE file) and in the individual files (the blurb we have in the =LICENSE entries of the modules). There is also an optional resources/license field in the META.yml spec: http://module-build.sourceforge.net/META-spec-current.html#resources which can be a URL to the full text of the license. TPF, more specifically Allison took upon herself to check this with real lawyers so we'll have a clear recommendation on *how* to declare our license in the distributions. I hope the recommendation will also include specific instructions on how to say we are using the perl license as that is what the majority is using now. Anyway this 6th issue will be dealt with later when we have the recommendation. For now, please let me know if you have any opinion on 1-4 ? regards Gabor http://szabgab.com/blog.html
Re: Integrating license related things of CPAN
On Thu, Oct 23, 2008 at 4:51 AM, Ken Williams [EMAIL PROTECTED] wrote: On Wed, Oct 22, 2008 at 6:09 AM, Gabor Szabo [EMAIL PROTECTED] wrote: 6) In this mail I have not yet dealt with how exactly the license is spelled out in the distribution (eg. LICENSE file) and in the individual files (the blurb we have in the =LICENSE entries of the modules). Lately I've been thinking that the 'dist' phase should automatically write out a LICENSE or COPYING file with the full text of the license. That way the author could declare the license once, in the Build.PL, and not have to mention it in (or keep it in sync with) the POD in the .pm files. Automatically writing a LICENSE file (probably using Software::License) might be good legally but I am not sure, the plain multiplication of those texts is necessary. Not keeping =LICENSE and =COPYRIGHT entries in the POD in .pm files - if that's what you were suggesting - seems to me like a step backwards in the strength of the license. At least if I am not mistaken the Debian people would prefer if we had the copyright and license in *every* file. Anyway I am not a lawyer so I'd wait with this till Allison can get a real legal advice of what *should* be the form of the license and copyright. I hope she will be able to get this information soon and then we can move forward with the implementation of the various parts of it. regards Gabor
Re: Integrating license related things of CPAN
On Wed, Oct 22, 2008 at 11:21 PM, Eric Wilhelm [EMAIL PROTECTED] wrote: # from Paul LeoNerd Evans # on Wednesday 22 October 2008: On Wed, Oct 22, 2008 at 11:52:27AM -0700, Eric Wilhelm wrote: While that might be annoying (once -- for the author), the tool can't get around that if it is a required field -- because any other behavior wouldn't comply with the META.yml spec. I suppose that's a fair point. I'm just thinking of the case where someone will just put anything in the field to shut up the tool because they just want to get on with it. Well, I think Module::Build will give you a nice error about that telling you what options are valid. If it doesn't, that would be a neat patch. As Gabor pointed out (I think only on IRC), the META.yml spec and the Module::Build docs are a bit too intertwined on this point. Also a good thing to patch. As discussed also in IRC it might be probably better if the META.yml spec was moved to a separate repository so it will be disassociated from Module::Build as META.yml is more, err meta than MB. It was also suggested that we discuss this on the cpan-metadata list. We could move the discussion there but I think the module-authors list is a better place as the module-authors should be involved in the evolving specification. If I am not mistaken Ken is the owner of the MB repository So Ken, would you be ready to move the META.yml spec to another repository? Would you first prefer to move whatever has to be moved from the docs of MB to META.yml and move it then? I know of the list of licenses that should be moved but there might be others. I'd be glad to put some (little) time in helping out in this. regards Gabor
Re: Integrating license related things of CPAN
On Fri, Oct 24, 2008 at 10:11 PM, Bill Ward [EMAIL PROTECTED] wrote: On Fri, Oct 24, 2008 at 4:01 AM, Alexandr Ciornii [EMAIL PROTECTED] wrote: Bill Ward wrote: 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. It is 5.10 now (for a half year or so). Not according to perl.com (http://www.perl.com/download.csp): Please. if anyone wants to discuss which version of perl is stable or why isnt 5.10.0 marked as such, please open a separate thread. This is irrelevant to the license issue. http://5.8.8. The version of ExtUtils::MakeMaker included in 5.8.8 distributions does not support the license field. And they would not see error (as we have no means to modify EU::MM at their computers). Only when they upgrade to EU::MM that has mandatory license or to 5.10.1 (maybe 5.8.9), they would see this error. Yeah I misunderstood at first, I thought the error would occur at the time of uploading to CPAN rather than at make dist time. There was such a suggestion on the thread but I don't think we should go that far in enforcing it. Anyway, even without any enforcing we should at least make the possible values clear and easy to use. What we need now is 1) moving the list of licenses from the MB::API to the META.yml spec 2) Adding the missing licenses to Software::License (the licenses that are in the API/spec already but not in SL) 3) Changing the META.yml spec to include more Open source licenses. (All the licenses from SL ?) 4) IMHO we need a way to indicate that none of the defined licenses fit your module. There is an option to call it unknown but IMHO some other word would describe the situation better. Maybe other? 5) There are modules that have parts with different licenses. e.g. DBD::SQlite includes third party code with different license. No matter what the relationship between the two (or more) licenses, we should somehow indicated in the META.yml what is the license. In general IMHO this is something we can never define well for all the possible cases so maybe all such modules should set license field to other saying that I am aware of the filed but cannot use it to describe the license exactly. Gabor
Re: Integrating license related things of CPAN
On Fri, Oct 24, 2008 at 10:11 PM, Bill Ward [EMAIL PROTECTED] wrote: On Fri, Oct 24, 2008 at 4:01 AM, Alexandr Ciornii [EMAIL PROTECTED] wrote: Bill Ward wrote: 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. It is 5.10 now (for a half year or so). Not according to perl.com (http://www.perl.com/download.csp): Please. if anyone wants to discuss which version of perl is stable or why isnt 5.10.0 marked as such, please open a separate thread. This is irrelevant to the license issue. http://5.8.8. The version of ExtUtils::MakeMaker included in 5.8.8 distributions does not support the license field. And they would not see error (as we have no means to modify EU::MM at their computers). Only when they upgrade to EU::MM that has mandatory license or to 5.10.1 (maybe 5.8.9), they would see this error. Yeah I misunderstood at first, I thought the error would occur at the time of uploading to CPAN rather than at make dist time. There was such a suggestion on the thread but I don't think we should go that far in enforcing it. Anyway, even without any enforcing we should at least make the possible values clear and easy to use. What we need now is 1) moving the list of licenses from the MB::API to the META.yml spec 2) Adding the missing licenses to Software::License (the licenses that are in the API/spec already but not in SL) 3) Changing the META.yml spec to include more Open source licenses. (All the licenses from SL ?) 4) IMHO we need a way to indicate that none of the defined licenses fit your module. There is an option to call it unknown but IMHO some other word would describe the situation better. Maybe other? 5) There are modules that have parts with different licenses. e.g. DBD::SQlite includes third party code with different license. No matter what the relationship between the two (or more) licenses, we should somehow indicated in the META.yml what is the license. In general IMHO this is something we can never define well for all the possible cases so maybe all such modules should set license field to other saying that I am aware of the filed but cannot use it to describe the license exactly. Gabor
Re: Integrating license related things of CPAN
On Sun, Oct 26, 2008 at 8:38 AM, Bill Ward [EMAIL PROTECTED] wrote: On Sat, Oct 25, 2008 at 11:08 PM, Jonathan Rockway [EMAIL PROTECTED] wrote: Some other thoughts... is the license specified in the META.yml legally binding in any way? If not, anyone using the module will have to look at the rest of the distribution to determine its license, again negating the usefulness of this field. Another good point. One could put GPL in the META.yml but have a LICENSE section in the POD that says same terms as Perl itself -- which one wins? Once we have a clear definition of what should be the text in the POD section CPANTS will check if the licenses are the same. Actually I am sure we'll be able to upload a stand alone module that will check it and I think if you use Dist::Zilla you won't have to care as it will insert the right thing everywhere base on the license keyword you give it. Then again, I, as the author, don't really know what license my distributions are distributed under. I could pick one, but can I really be sure that it applies? If I use Term::ReadLine and it picks the Term::ReadLine::Gnu, is my module GPL now? I don't know and I don't care. Does anyone else? Some people care a lot; to others it doesn't matter so long as it's available. There are some major differences between the licenses, mainly around what can be done with derivative works, but that's a lot less likely to be an issue with a Perl module. I know, at some of my clients the license issue is critical. Some of the downstream distributors (Debian, Fedora ) are also very picky about the licensing terms. They might be extreme but I prefer these over the other extreme that says: oh its free software, we can do whatever want with it and then go on and redistribute a GPL software in their proprietary application. So I'd rather make it easy to check the license. Gabor Szabo http://szabgab.com/blog.html
Re: Integrating license related things of CPAN
On Thu, Oct 30, 2008 at 7:18 AM, Bill Ward [EMAIL PROTECTED] wrote: I think supporting options like other or mixed should resolve most of these cases. Sure, automatic tools that use this field will be out of luck, but that should be a fairly small minority. This is exactly what I mean. I think setting 'other' as the license should indicate that the developer is aware of this field and cares but that the available options don't fit. This is IMHO much better then nothing or 'unknown'. Gabor
META.yml how to declare the need for threaded perl?
Hi,
currently I have this code in Build.PL to check if the perl where Padre
is being installed is threaded.
use Config;
if (not $Config{usethreads}) {
warn Padre requires a perl built using threads\n;
exit 0;
}
Is there any way to add this requirement to META.yml?
Gabor
Re: META.yml how to declare the need for threaded perl?
On Fri, Oct 31, 2008 at 4:14 PM, Jonathan Rockway [EMAIL PROTECTED] wrote:
* On Fri, Oct 31 2008, Gabor Szabo wrote:
Hi,
currently I have this code in Build.PL to check if the perl where Padre
is being installed is threaded.
use Config;
if (not $Config{usethreads}) {
warn Padre requires a perl built using threads\n;
exit 0;
}
Probably off topic, but last time I tried Padre, I commented out all the
references to threads (non-threaded perl here) and it worked fine.
Maybe it doesn't really require threads?
Currently it only uses it in the Ack menu option.
I think as we introduce more and more long-running processes
(e.g. indexing all the pods, running your tests in the background etc)
we will need that.
I guess we can implement everything with fork but I think -
maybe because of my lack of experience in threads - that it will
be better to use them than to fork.
Id' be glad to hear your opinion too.
Gabor
Re: Distribution version vs. Main package version
On Mon, Nov 10, 2008 at 11:43 PM, Ricardo SIGNES [EMAIL PROTECTED] wrote: * 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. Regarding APIs, I'd add a separate API number that only changes when the API changes. Gabor
Re: Distribution version vs. Main package version
On Thu, Nov 13, 2008 at 1:28 AM, Ricardo SIGNES [EMAIL PROTECTED] wrote: * 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. to further go OT :-) Instead of advocating the reduction of dependencies IMHO we should further improve our distribution methods. Downstream repackaging (Debian, Fedora etc), binary packages (ppm, par), stable CPAN ( http://news.perlfoundation.org/2008/08/2008q3_grant_proposal_cpan_sta.html ) Gabor
META.yml license field - update
A month ago we had a discussion about the license field of META.yml Back then there were 10,235 modules on CPAN without a license field in META.yml. Today I checked it again an there are now 10,264 such modules. Now either people still don't know about it, don't care or there is a bug in CPANTS that does not know how to check it. http://cpants.perl.org/dist/shortcoming?metric=metayml_has_license Can anyone point me at a module that has license field (with a value that is not undef) in the META.yml and CPANTS does not recognize it? Gabor http://szabgab.com/blog/2008/11/1227608301.html
Re: META.yml license field - update
On Tue, Nov 25, 2008 at 12:59 PM, Martin Evans [EMAIL PROTECTED] wrote: Gabor Szabo wrote: A month ago we had a discussion about the license field of META.yml Back then there were 10,235 modules on CPAN without a license field in META.yml. Today I checked it again an there are now 10,264 such modules. Now either people still don't know about it, don't care or there is a bug in CPANTS that does not know how to check it. http://cpants.perl.org/dist/shortcoming?metric=metayml_has_license Can anyone point me at a module that has license field (with a value that is not undef) in the META.yml and CPANTS does not recognize it? Gabor http://szabgab.com/blog/2008/11/1227608301.html Not 100% sure but try http://cpants.perl.org/dist/kwalitee/DBIx-Log4perl http://search.cpan.org/src/MJEVANS/DBIx-Log4perl-0.13/META.yml its license field is ~ (that is empty) That's not good either, along with fields that are undef. Gabor
Re: Automated testing
On Sat, Nov 29, 2008 at 6:08 AM, Andy Lester [EMAIL PROTECTED] wrote: On Nov 28, 2008, at 9:55 PM, David Golden wrote: You might want to look at Smolder: http://www.slideshare.net/mpeters/smolder-introduction Smolder doesn't run tests. It only reports on the results. Look at http://search.cpan.org/~drolsky/SmokeRunner-Multi-0.14/ I was not the OP but I was glad to see this post as I just wanted to setup smoke testing on the Padre SVN repository. I tired SmokeRunner::Multi with partial success. http://www.perlmonks.org/?node_id=726817 In short it seems that currently it does not create correct TAP archives so I could not use it yet. I already sent a message to Dave, I hope he'll have time to check what might have gone wrong. For now I think buildbot http://buildbot.net/ is a better solution. One might integrate buildbot - that runs the full cycle - with Smolder that can hold the TAP result and display them in a nice way. Eventually I'd like to see a full integration of something that will do the build/test cycle and store all the data, both the output from the build commands and the TAP results. BTW PostgreSQL also has a very nice home-brew system. Gabor
Re: utf-8 in PODs on search.cpan.org and Kobesearch
On Sat, Feb 14, 2009 at 8:31 PM, Eric Wilhelm scratchcomput...@gmail.com wrote: # from Gabor Szabo # on Saturday 14 February 2009 09:43: Unfortunately neither search.cpan.org nor Kobesearch show them correctly. Yes, see 'encoding' in http://perldoc.perl.org/perlpod.html http://search.cpan.org/perldoc?lambda With the the new 0.28 release we can see the unicode names http://search.cpan.org/dist/Padre/lib/Padre.pm thanks for your help! Gabor
Re: Help Needed in Sorting and Updating the List of Perl Mailing Lists
Hi everyone, I am sorry I write only now but I was busy. So I was the one who copied the data and I am sorry I did not ask you Elaine first to access the database. Guys please, let's not play the blaming game. That does not lead to any good place. If I can get access to the database I might be able to update the data a bit. If I can get the data dump I am ok with hosting the site assuming both you Elaine and Ask and Robert and whoever else has a say in it agree. AFAIK both lists.perl.org and lists.cpan.org show the same content but currently they point to different IP addresses. regards Gabor On Tue, May 12, 2009 at 2:45 AM, Elaine Ashton eash...@mac.com wrote: On May 11, 2009, at 6:51 PM, Bill Ward wrote: I think the blame game is silly here - we should be looking for solutions moving forward, not who's fault things are. The best thing to do now, IMHO, would be to either change the hosting or keep it where it is but grant access to let others help maintain it. Is that an option you'd consider? Oh, getting upbraided for having a baby and not having time to read email is amusement I could only get from perl. :) I laid out the options and yes, I've given accounts to people before and I can still if there are interested parties. e.
Re: What's the current 'best practices' for module license
On Wed, Aug 26, 2009 at 7:09 PM, Geoffrey Leachge...@hughes.net wrote: Some time back here was an extensive discussion of module licenses. I ignored it at the time, but now I regret that. Can someone point me to a conclusion? Or, is it sufficient to use Software::License::Perl_5? Thanks. Allison recently sent me this link on TPF: http://www.perlfoundation.org/cpan_licensing_guidelines Gabor
updating CPAN::Forum
Hi, For a long time I have not touched the CPAN::Forum web site but as a new years resolution I started to work on it again. So far most of the changes were internal - switched to new server - switched to PostgreSQL - moved to mod_perl - e-mails are sent in asynchronous mode All this made the web site a lot faster Also - the templating system was switched to Template::Toolkit - the version control to git - many tests were added Some more cleanup and I can start to add features. I'll have some time in the coming 2-3 months to improve the forum and provide a much better platform to support the module authors. So here is the reason I am writing. I'd like to ask the module authors to 1) Check if there are unanswered questions related to your modules and try to answer them 2) Let me know what are the features that might help you the most? You can see all the post regarding all the distributions you uploaded to CPAN. e.g. for me this is the link: http://cpanforum.com/author/SZABGAB thanks Gabor http://cpanforum.com/
how to give a list of alternative requirements?
Hi, I am trying to create a Makefile.PL using Module::Install for Bugzilla so it can be uploaded to CPAN. There are many issues I'll have to deal with but here is one that might be relevant to others. Currently Bugzilla can be installed with either MySQL, PostgreSQL or Oracle. When checking for the prerequisites I'd like to let the user tell which one she is going to use and then make sure the relevant database driver is installed. How would you do this and how should that be done so automated testers will also be able to test the package? regards Gabor -- Gabor Szabo http://szabgab.com/
Re: Merging two CPAN modules
On Thu, May 27, 2010 at 7:12 PM, David Precious dav...@preshweb.co.uk wrote: On Thursday 27 May 2010 16:44:58 Matt Grimm wrote: The question is, how do I go about retiring one module on CPAN once the merge is complete? I suppose the safest route might be to add a big comment at the top of the retired module's Pod to indicate that it is no longer maintained and users should start using the other module. That would seem to make sense. Depending on how similar the modules are, you might be able to release a skeleton YAML::AppConfig as a wrapper using Config::YAML to do the actual work, so that people already using YAML::AppConfig don't find their code suddenly breaking. That may be overkill though, and simply leaving the existing code (assuming it works well enough at the moment) with a this is now deprecated, use Config::YAML which is actively developed may be sufficient. IMHO it would be nice to provide a migration path. A document, or just a few examples on how to migrate from the deprecated module to the new one. Gabor
Re: Why are you releasing modules to CPAN?
Some people might feel this related: The surprising truth about what motivates us http://www.youtube.com/watch?v=u6XAPnuFjJc Gabor
Re: Hebrew character conversion module
On Mon, Nov 8, 2010 at 10:56 PM, Lars Dɪᴇᴄᴋᴏᴡ 迪拉斯 da...@cpan.org wrote: What if I don't want it to use that Encode interface? I just want it to be a module on its own. Any good reason for doing so? This goes against two expectations set up by CPAN precedent: • All modules that deal with encoding/decoding are compatible with Encode. • All modules in the Encode namespace adher to the Encode interface. Being the odd man out sucks. http://cpanratings.perl.org/dist/Ed2k_link Tzadik, I assume you've already implemented the module and the API. Could you show us how it looks like? Either code or the documentation with examples. That might give people a better chance to understand what and how are you doing. Gabor
What hurts you the most in Perl?
The other day I was at a client that uses Perl in part of their system and we talked a bit about the language and how we try to promote it at various events. Their Perl person then told me he would not use Perl now for a large application because: 1) Threads do not work well - they are better in Python and in Java. 2) Using signals and signal handlers regularly crashes perl. 3) He also mentioned that he thinks the OO system of Perl is a hack - that the objects are hash refs and there is no privacy. So I wonder what hurts *you* the most in Perl? Gabor -- Gabor Szabo http://szabgab.com/ Perl Ecosystem Group http://perl-ecosystem.org/
Re: What hurts you the most in Perl?
On Wed, Dec 1, 2010 at 6:21 PM, Lyle webmas...@cosmicperl.com wrote: I wasn't *shitting* as you put it, on other peoples work. At least no more so than Bill's original comment about Perl 6. I expressed my opinion only and should be free to do so. I already asked Bill in my response to refrain from such comments. I don't think that having freedom of speech means we should not care about the feelings of our fellow Perl mongers and we should not respect their work. Don't take things so personally. I don't think Dave really needs me here but I don't think he took it personally. I think you felt you have a right to trash Moose because Perl 6 was trashed. Can we drop this direction of the discussion now? BTW installing Moose takes some time. It might even be very difficult on a server where you don't have command line access but I never tried that. I don't think that is the source of the problem. I think we had of the difficult installation issue a lot before Moose was developed. With that said, we need solution for that. Gabor
Re: What hurts you the most in Perl?
On Wed, Dec 1, 2010 at 7:21 PM, David Cantrell da...@cantrell.org.uk wrote: On Sun, Nov 28, 2010 at 08:03:54PM -0800, Jarrod Overson wrote: The inability for an IDE to help me thoroughly refactor code is the biggest problem for me. Can Padre do that yet? In a very limited way. There has been some work providing some refactoring tools and IMHO all of them were already integrated with vim but it is very far from what I wanted. And is there a working binary for OS X that I can just download and run without wasting a day fighting against Wx? Unfortunatelly not. I am now trying again to build an .exe for Windows using PAR. If that is successful then we might have a chance to build similar packages for Linux and OS X.. Regardless if your favorit editor can integrate with external scripts then you can try to integrate the same tools as have been done with vim and we can further cooperate on refactoring tools. Gabor
Re: What hurts you the most in Perl?
On Wed, Dec 1, 2010 at 11:22 PM, Bill Ward b...@wards.net wrote: I wasn't shitting on Perl 6. Oh, then sorry for my wording. The technology is fine. But we (collectively, the Perl community) suck at marketing. The perception I hear everywhere I go is that Perl is a dead-end language, and will soon go the way of Fortran or COBOL. It's too late to change that. But maybe if Perl 6 were released under a totally new name it could gain traction the way Ruby has done. Sure, Perl needs some technological improvements and I think people involved in p5p have been doing some nice things lately at an increasing speed. Many modules on CPAN also need improvements. But even what we have today we could achieve much better results if the perception of people was better. With my original question I wanted to know what technological and perception related issues people see. We already got some material but I'd be happy to see more comments. Especially from those who work with people who are not involved in the Perl community. How do your peers and your bosses see Perl? I don't think it is too late. I think we just need to get up and start talking to people outside of the Perl community. That's what I have been trying to push forward with varrying success via the TPF Events group. https://www.socialtext.net/perl5/index.cgi?events Gabor
Re: What hurts you the most in Perl?
On Thu, Dec 2, 2010 at 1:58 AM, Octavian Rasnita orasn...@gmail.com wrote: From: Gabor Szabo szab...@gmail.com I am now trying again to build an .exe for Windows using PAR. If that is successful then we might have a chance to build similar packages for Linux and OS X.. Please dont forget about ActivePerl. :-) As far as I know there are ppm packages for Padre maintained by Mark Dootson. He just announced the latest versions 2 weeks ago: http://mail.perlide.org/pipermail/padre-dev/2010-November/002149.html Are those not working for you? regards Gabor ps. Probbaly we should mentione them on our download page as well http://padre.perlide.org/download.html
Re: What hurts you the most in Perl?
On Thu, Dec 2, 2010 at 9:41 AM, Eric Wilhelm enoba...@gmail.com wrote: # from Gabor Szabo # on Wednesday 01 December 2010 13:46: Many modules on CPAN also need improvements. But even what we have today we could achieve much better results if the perception of people was better. With my original question I wanted to know what technological and perception related issues people see. We already got some material but I'd be happy to see more comments. Especially from those who work with people who are not involved in the Perl community. How do your peers and your bosses see Perl? We have all heard the conventional wisdom that perl is dead. But, anything related to perception which cannot be solved by writing modules is probably off-topic for this list. I think this is one of the issues we have. For every topic we tend to setup a separate mailing list (or sometimes more) and try to segregate the people to that list. So there is an advocacy list a marketing list - both are almost deserted. The latter does not even have a public archive. In the meantime module-authors arrive to the conclusion that they need to change language in order to put food on the table. And I don't blame them. I'd go further. Because we have all these perl specific mailing list we tend to talk among ourselves. Which is safe (well, except of the occassional trashing and bashing) but which means others don't hear us and we don't hear others. Technological issues with the CPAN and its modules abound. We have 20+ years worth of code and archives to maintain and we're running short on maintainers. See here: http://kfsone.wordpress.com/2010/11/30/take-that-python/ So what are the plans. How do we get more people to maintain code on CPAN? And what are the priorities? Most people will want to spend their time on writing new fun code. Maintaining old code, documenting it, fixing obscure bugs, making sure it also works on windows. None of these are priorities of the average Open source Perl developers. OTOH companies invested in Perl tend to want that too. Gabor ps. Have I already mentioned that this is the gap we are trying to bridge with the Perl Ecosystem Group?
What is your preferred way to get help?
I guess each module author has his/her own preferred way how to get patches and other forms of help. I have started to work on a series of talks - that I'd probably develop with a series of blog posts - on how to contribute to and open source project with heavy focus on Perl projects. If interested, I posted my talk proposal on the mailing list of Israel.pm: http://mail.perl.org.il/pipermail/perl/2011-January/011524.html My objective is getting more people to contribute to CPAN. I don't necessarily want more modules. I'd prefer to get more people involved in maintaining and improving the already existing module. So I wonder what is the preferred way for you to get help? What should I stress in my blogs and presentation and what should I recommend against? What items do you think I might have missed from that draft? regards Gabor
Interesting licensing requires written permission of the author to modify it
Hi I found a module on CPAN http://search.cpan.org/~goyali/google_talk_bot_v_01/ with the following comment regarding licensing: You are not allowed to modify the script unless having the written permission of abhishek jain I am just wondering if having such code on CPAN is really what we want. It might be useful to someone but it is unclear to me if you could use parts of it in your code without the 'written permission of abhishek jain' or if that's considered modifying the code. To be on the safe side I decided to not even try the code so I won't need to look at it which might break the license. What do you think? Gabor
Making sure your module works on other OS-es as well
Hi, some of you might know that Perl is quite underrepresented in the Windows world. So although my main OS is Linux I thought giving a hand there might be interesting. Therefore recently I started to run a CPAN smoker http://www.cpantesters.org/ on a Windows XP machine running Strawberry Perl 5.12.3. I encountered a number of modules that got stuck on during the smoking. In some cases I spent some time trying to figure out the issue or at least to report to the author and sometimes to RT. In some of the cases I got quick replies and in a few cases the module was fixed in hours. This made me very happy and it felt my time was well spent. Still, I guess in the majority of the cases the tests just failed, the report was sent to the http://www.cpantesters.org/ and the authors got notified. I assume that some of you are running Linux only and might have no clue at all how to make your module work on Windows. I don't know much either but at least I have a Windows running in a VirtualBox so I can try things and report them back. Luckily there are some folks on both the CPAN Testers mailing list http://lists.perl.org/list/cpan-testers-discuss.html and on the Vanilla Perl list http://win32.perl.org/wiki/index.php?title=Win32_Mailing_Lists (subscribe by sending empty message to win32-vanilla-subscr...@perl.org who actually know Windows quite well. So I'd like to ask you all to check the test reports of your modules and if you have consistent failures of one of your modules on Windows then try to fix them. If you need any help, please send a message on either of those mailing list asking people how to fix specific Windows related issues. You can see the report matrix of your modules by visiting http://matrix.cpantesters.org/?author=pauseid just replace pauseid with your pauseid in lowercase. thank you for your time! regards Gabor -- Gabor Szabo http://szabgab.com/
Re: Making sure your module works on other OS-es as well
On Fri, Jul 1, 2011 at 4:23 PM, David Cantrell da...@cantrell.org.uk wrote:
On Fri, Jul 01, 2011 at 03:11:08PM +0300, Gabor Szabo wrote:
So I'd like to ask you all to check the test reports of your modules and if
you
have consistent failures of one of your modules on Windows then try to fix
them.
If you need any help, please send a message on either of those mailing list
asking people how to fix specific Windows related issues.
I went through a period of trying to make sure my code worked on
Windows, but I've given up. Not because it's hard to do - it generally
isn't - but the complete lack of a reasonable set of tools* on Windows,
which just makes me angry whenever I have to touch the blasted thing,
made me stop.
Indeed the issues I encountered were all quite simple:
1) This code in test:
`date file`
On Windows the date command waits for input so this got the test stuck.
Probably many testers just put this module in the disabled list so it
will be never tested.
2) the separator of PATH is not : on Windows so this code:
$ENV{PATH} = 'mypath' . ':' . $ENV{PATH}
is incorrect. I think the right approach is to
use Config;
$ENV{PATH} = 'mypath' . $config{} . $ENV{PATH}
3) running external perl scripts
Code like this (in a test)
`path/to/other/perl/script param param`
is not a good idea on Linux either as this will use the perl in the sh-bang
instead of the current perl which is running the tests.
These might be different version of Perl.
Besides, on Windows the above to work needs special configuration that not
all the Perl installers provide. The better approach is to write:
`$^X path/to/other/perl/script param param`
Though I really prefer
qx{$^X path/to/other/perl/script param param}
Thank you for you consideration of the other 80% of people who are
still using Windows.
regards
Gabor
Re: Making sure your module works on other OS-es as well
Lovely, so now instead of talking about how to make sure our modules work on other OS-es we are going to discuss how Gabor is offending Dave? I wrote a lengthy response pointing out various things but I think I'd rather just apologize. Dave, I am sorry I did not mean to offend you. Keep up the good work. Actually, according to the matrix http://matrix.cpantesters.org/?author=dcantrell most of your modules have success test reports from Windows. Everyone, I hope we can now get back and see how we can mutually help each other to make it easy for all of us to have our modules support a wider range of operating systems. regards Gabor
Re: Making sure your module works on other OS-es as well
On Sun, Jul 3, 2011 at 3:30 AM, Shmuel Fomberg ow...@semuel.co.il wrote: On 2011/07/03 8:50, David Golden wrote: If authors don't want failure reports on ancient Perls, they are advised to be explicit with use 5.006 or use 5.008009 or whatever is the earliest version they choose to support. Let's file it under 'do the right thing by default'. Of course an author can specify which version he supports. but by blocking old version he won't have to. That would require a central authority to decide what is the right thing instead of just providing data an letting the module author and the user to decide. I know you know there are companies still using 5.6.x... The distro count in http://pass.cpantesters.org/ might give a better indication on which version of perl is supported by CPAN distribution. Though maybe it would be better to default to only show the production releases of perl and maybe also to include %-ages and/or a graph. It shows that 11,356 have PASS-ing reports on 5.6.1 5.10 has the biggest number that is 21,360. regards Gabor
Re: Making sure your module works on other OS-es as well
On Sat, Jul 2, 2011 at 6:29 PM, Shmuel Fomberg ow...@semuel.co.il wrote: Hi Gabor. 3) running external perl scripts Code like this (in a test) `path/to/other/perl/script param param` is not a good idea on Linux either as this will use the perl in the sh-bang instead of the current perl which is running the tests. These might be different version of Perl. Btw, related to your comment, I think that Padre run itself using wxPerl, without regarding on which Perl it is running. So it I have two Perl versions installed, and both of them have Wx, and tries to run padre as perl5.xx.x padre.pl, it will actually run on whatever Perl that was installed last instead. If I am not mistaken you are running on Mac OSX. I know there is some special casing for that in our code but I don't have a Mac to try it. As I mentioned on other channels Mark Dootson might be the best person to talk to regarding this as he is familiar with Mac and is also a Padre developer. In any case I'd appreciate if we could handle bug reports on the #padre IRC channel or on the padre-dev mailing list. See them here: http://padre.perlide.org/contact.html Regards Gabor
How to list optional dependencies?
Hi, I was looking at ExtUtils::MakeMaker and wondering how could I list a set of modules as optional dependencies? As I could not find and answer I wonder if there is a well defined tool for this in any of the packaging tools of Perl? If not, what is the recommended way to say in Makefile.PL and/or Build.PL: I don't require Module::Name version 2.7 but I'd work much faster/better/cleaner if I had it. Shall I install it? regards Gabor
MetaCPAN is quickly becoming the de-facto interface to CPAN
In case you don't have time to follow the many blog post of the Perl community I think this is an item worth reading for you as a Module Author. Don't be left out from the new CPAN game! This Week in MetaCPAN by Olaf Alders http://blogs.perl.org/users/olaf_alders/2011/07/this-week-in-metacpan.html regards Gabor
Re: MetaCPAN is quickly becoming the de-facto interface to CPAN
On Fri, Jul 29, 2011 at 2:58 PM, sawyer x xsawy...@gmail.com wrote: On Fri, Jul 29, 2011 at 2:24 PM, Shlomi Fish shlo...@shlomifish.org wrote: Hi Gabor, On Fri, 29 Jul 2011 12:58:52 +0300 Gabor Szabo szab...@gmail.com wrote: In case you don't have time to follow the many blog post of the Perl community I think this is an item worth reading for you as a Module Author. Don't be left out from the new CPAN game! One reason I have not converted wholesale to metacpan is because it redirects all http:// requests to https:// . Very annoying. I'd say very correct! I think I used to[1] get alerts on metacpan that some of the content is coming via http while the main page is https. I wonder if this is not breaking the whole idea of privacy? Gabor [1] I don't get them any more as I turned them off.
How do I indicated modules used by Makefile.PL (or Build.PL) ?
In a distribution I would like to use a module (specifically File::Copy::Recursive ) within Makefile.PL How can I do this? How do you do this? I am using Module::Install so I would be mostly interested in that solution but if you have this solved for the other packaging tools, please do share that too. If I just say use File::Copy::Recursive; it will blow up on systems that don't have the module installed. So I tried configure_requires 'File::Copy::Recursive' = 0; require File::Copy::Recursive; but that still blows up when I run Makefile.PL I wonder if this will work once it is packaged and when the META.yml has the configure_requires field already or if I need another way to make sure File::Copy::Recursive is installed before Makefile.PL is executed? regards Gabor
