Re: New fields for META.yml
Andy Lester wrote: I'm moving my bug queue for WWW::Mechanize and Test::WWW::Mechanize over to Google Code, which is also where I host the source code. I think it'd be a good idea if META.yml had fields that say where the bug queue is, and where the source code lives. That way search.cpan.org, and any others, could refer to the proper URLs, because very soon, the link at http://search.cpan.org/dist/WWW-Mechanize/ that points to the queue at http://rt.cpan.org/NoAuth/Bugs.html?Dist=WWW-Mechanize is going to be wrong. Also, a project home page would be swell as well. Schwern: Is this your ball? No, but I went back in my time machine and made sure it's there because I'm that kind of guy. http://module-build.sourceforge.net/META-spec.html#resources -- Stabbing you in the face for your own good.
Re: New fields for META.yml
A. Pagaltzis schreef: * Andy Lester [EMAIL PROTECTED] [2007-10-29 17:45]: I think it'd be a good idea if META.yml had fields that say where the bug queue is, and where the source code lives. That way search.cpan.org, and any others, could refer to the proper URLs ??? The META.yml files in older versions of your distro can???t change even though the info in them would no longer be correct. Surely that's no problem? Before reporting a bug, people will (or should?) first install (or at least check) the latest version of the ditribution, to check if it's already been fixed. Eugene
New fields for META.yml
I'm moving my bug queue for WWW::Mechanize and Test::WWW::Mechanize over to Google Code, which is also where I host the source code. I think it'd be a good idea if META.yml had fields that say where the bug queue is, and where the source code lives. That way search.cpan.org, and any others, could refer to the proper URLs, because very soon, the link at http://search.cpan.org/dist/WWW- Mechanize/ that points to the queue at http://rt.cpan.org/NoAuth/ Bugs.html?Dist=WWW-Mechanize is going to be wrong. Also, a project home page would be swell as well. Schwern: Is this your ball? xoxo, Andy -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: New fields for META.yml
On Mon, Oct 29, 2007 at 11:43:30AM -0500, Andy Lester wrote: I think it'd be a good idea if META.yml had fields that say where the bug queue is ... I'm far more likely to submit a bug report once I've got your stuff installed and am using it (or trying to use it) than I am while trying to install it. By that time, CPAN.pm will have cleared up the build directory and I won't have a copy of your META.yml handy. Also, automated tools are, umm, not very likely to submit bug reports. Consequently, having it in a machine-readable META.yml file doesn't seem very useful. Put it in the docs instead. -- David Cantrell | Godless Liberal Elitist For every vengeance, there is an equal and opposite revengeance. -- Cartoon Law X
Re: New fields for META.yml
# from David Cantrell # on Monday 29 October 2007 10:00: By that time, CPAN.pm will have cleared up the build directory and I won't have a copy of your META.yml handy. Maybe CPAN.pm should keep them handy? Of course, they can be systematically fetched from your friendly CPAN mirror. Consequently, having it in a machine-readable META.yml file doesn't seem very useful. Put it in the docs instead. Maybe in the docs as well, but machine-readable would be quite convenient for e.g. a helper tool to launch your browser (or even (given some sort of discoverable web service API) fill-out the details of the report (starting with the module version, perl version, osname, and other Config.pm yummies which are so often missing from reports), plus possibly wizarding the user through the all-important search for bug step.) --Eric -- Those who cannot remember the past are condemned to repeat it. --George Santayana --- http://scratchcomputing.com ---
Re: New fields for META.yml
# from Andy Lester
# on Monday 29 October 2007 09:43:
I think it'd be a good idea if META.yml had fields that say where the
bug queue is, and where the source code lives.
It already does.
Also, a project home page would be swell as well.
In the 'resources' hash, the 'bugtracker', 'repository', and 'homepage'
keys are defined in the spec.
http://module-build.sourceforge.net/META-spec-current.html#resources
In your Build.PL, just use the 'meta_merge' key.
meta_merge = { resources = { repository = ... } },
See e.g.
http://search.cpan.org/src/KWILLIAMS/Module-Build-0.2808/Build.PL
--Eric
--
Introducing change is like pulling off a bandage: the pain is a memory
almost as soon as you feel it.
--Paul Graham
---
http://scratchcomputing.com
---
Re: New fields for META.yml
automated tools are, umm, not very likely to submit bug reports. Consequently, having it in a machine-readable META.yml file doesn't seem very useful. Put it in the docs instead. Please do me the courtesy of reading the entire message. Repeating the part that it seems you missed: That way search.cpan.org, and any others, could refer to the proper URLs, because very soon, the link at http://search.cpan.org/dist/WWW- Mechanize/ that points to the queue at http://rt.cpan.org/NoAuth/ Bugs.html?Dist=WWW-Mechanize is going to be wrong. Also, a project home page would be swell as well. It has nothing to do with humans reading the META.yml in the build directory, and everything to do with how search.cpan.org sees it. Thank you, Andy -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: New fields for META.yml
On Oct 29, 2007, at 12:10 PM, Eric Wilhelm wrote: It already does. Also, a project home page would be swell as well. In the 'resources' hash, the 'bugtracker', 'repository', and 'homepage' keys are defined in the spec. Ah, thank you. I'd assumed they didn't exist. Mea culpa. Now to see if EU::MM supports them -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: New fields for META.yml
On Oct 29, 2007, at 5:11 PM, A. Pagaltzis wrote: • The META.yml files in older versions of your distro can’t change even though the info in them would no longer be correct. • Doing this via META.yml means the only way to update this info is to push out a new release. Clearly this info should live somewhere and search.cpan should use it, but META.yml is the wrong place. It belongs somewhere unversioned. Best is the enemy of the good. Moving forward with META.yml for WWW::Mechanize and Test::WWW::Mechanize. xoa -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: New fields for META.yml
* Andy Lester [EMAIL PROTECTED] [2007-10-29 17:45]: I think it'd be a good idea if META.yml had fields that say where the bug queue is, and where the source code lives. That way search.cpan.org, and any others, could refer to the proper URLs • The META.yml files in older versions of your distro can’t change even though the info in them would no longer be correct. • Doing this via META.yml means the only way to update this info is to push out a new release. Clearly this info should live somewhere and search.cpan should use it, but META.yml is the wrong place. It belongs somewhere unversioned. Unfortunately we don’t already have such a thing, and setting it up just for the bugtracker etc. info involves much bigger changes by more people than the incremental changes needed for doing that via META.yml, so there’s virtually no point in me pointing out that we could do better, but anyway. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: New fields for META.yml
* Andy Lester [EMAIL PROTECTED] [2007-10-29 23:15]: Best is the enemy of the good. And next time this will be handy, it will also be too big a change vs. an incremental suboptimal solution, and the overnext time as well, and ever on. YAGNI does not apply either: this *is already* the overnext time. The gravatar spat would’ve been solved by something like that and I remember another discussion where we said that this would really be the right solution, though I no longer remember what it was about. And I haven’t been on the relevant mailing lists for that long, and I’m still not on all of them. Moving forward with META.yml for WWW::Mechanize and Test::WWW::Mechanize. Yeah, * A. Pagaltzis [EMAIL PROTECTED] [2007-10-29 23:15]: there’s virtually no point in me pointing out that we could do better, but anyway. of course. It’s just not gonna happen. Oh well. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: New fields for META.yml
On Mon, Oct 29, 2007 at 11:25:34PM +0100, A. Pagaltzis ([EMAIL PROTECTED]) wrote: * Andy Lester [EMAIL PROTECTED] [2007-10-29 23:15]: Best is the enemy of the good. And next time this will be handy, it will also be too big a change vs. an incremental suboptimal solution, and the overnext time as well, and ever on. What do you propose we do? The gravatar spat would’ve been solved by something like that and The Gravatar spat was entirely a non-problem. -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: New fields for META.yml
* Andy Lester [EMAIL PROTECTED] [2007-10-29 23:30]: On Mon, Oct 29, 2007 at 11:25:34PM +0100, A. Pagaltzis ([EMAIL PROTECTED]) wrote: * Andy Lester [EMAIL PROTECTED] [2007-10-29 23:15]: Best is the enemy of the good. And next time this will be handy, it will also be too big a change vs. an incremental suboptimal solution, and the overnext time as well, and ever on. What do you propose we do? I thought about it for a bit and found there are some faintly tricky questions. Nothing too serious, but I’m not entirely sure of all the answers, so I don’t have a proposal on hand. Mostly the questions are things like whether the data should live on the CPAN FTP itself or should search.cpan gain an account system? Maybe have PAUSE would provide a bunch of pages with settings and generate a file from them that would go on the FTP? The concern is “distance of metadata” I guess – it shouldn’t be too onerous for automatic tools working against the FTP, such as CPAN.pm, to get at this data, even though it lives outside the distribution. The 01mailrc.txt and 02packages.details.txt seem like obvious candidates but I don’t know how extensible their formats are? I don’t see any insurmountable problems, it’s just a matter of hashing out the choices and picking one. Is there honest interest? I am up for it if the people who’d need to play along are also. (Who maintains PAUSE f.ex.?) Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: New fields for META.yml
On 29 Oct 2007, at 22:25, A. Pagaltzis wrote: YAGNI does not apply either: this *is already* the overnext time. The gravatar spat would’ve been solved by something like that I missed that... Got a link? -- Andy Armstrong, Hexten
Re: New fields for META.yml
I thought about it for a bit and found there are some faintly tricky questions. Nothing too serious, but I’m not entirely sure of all the answers, so I don’t have a proposal on hand. Let me know when you get one then. In the mean time, I'm moving forward. Mostly the questions are things like whether the data should live on the CPAN FTP itself or should search.cpan gain an account system? search.cpan.org is not the CPAN. It is a view of the data. -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: New fields for META.yml
On 29 Oct 2007, at 23:33, Andy Armstrong wrote: I missed that... Got a link? Have now - thanks. -- Andy Armstrong, Hexten
