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: best is better than not best
# from A. Pagaltzis # on Monday 29 October 2007 15:25: * Andy Lester [EMAIL PROTECTED] [2007-10-29 23:15]: Best is the enemy of the good. No. Best is what the good should aim to be. If best is better than good, why choose the worst of the two? 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. Yep. What we usually end up with when someone says the perfect should not stand in the way of the good is almost-works standing in the way of good-enough or, as with the toolchain: forever-backwards-compatible-with-halfway-almost-ok. --Eric -- Chicken farmer's observation: Clunk is the past tense of cluck. --- http://scratchcomputing.com ---
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
Re: distributed/centralized META.yml data
# from A. Pagaltzis # on Monday 29 October 2007 15:11: Clearly this info should live somewhere and search.cpan should use it, but META.yml is the wrong place. It belongs somewhere unversioned. +1, and see-also: some kind of common API between all of the meta-ish foo.perl.org sites. http://www.nntp.perl.org/group/perl.module.build/2007/07/msg778.html I think META.yml can play a part in that, particularly in fostering distributed pioneering. The trouble with ad-hoc is just that it tends to *never* get formalized (i.e. never gets centrally documented, becomes discoverable, appears in books, etc.) Of course, the trouble with centralization is that it can resist, discourage, or stifle change. Plus, it is typically subject to the wisdom and latency of committees. 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. It seems like something more along the lines of web services plus sync would be better suited to distributed implementation. For example, meta.perl.org could be queried anonymously and edited by the author, but auto-filled (or even maybe over-written) by META.yml. The nice thing about just stick META.yml in your distro is that it can be supported by shipped tools (e.g. Module::Build, Module::Starter, etc.) This gives a nice low barrier to entry, and doesn't require as much opt-in or active engagement as e.g. editing something in a web form. Also, it comes with the tarball and is therefore not subject to network failure, it mirrors well, etc -- all of those nifty qualities have to be traded-off to get external updateable-ness, especially if your solution is not built-in to the centralized mirroring scheme (i.e. PAUSE.) Unfortunately, supporting multiple info sources (META.yml, plus a web-editable database somewhere and/or additional inputs such as cpanforum, etc) probably means attaching a version to the data and deciding which overrides which. Typically, the data source which doesn't require the author to know about external interfaces is the easiest one to get rolling -- i.e. META.yml. What if the tarball is newer than the last modification to the online data? Do fields from META.yml still get overridden by the online data? Should the meta.perl.org service try to extract/update data from META.yml? (Maybe just upon sign-up/request from the author?) Perhaps META.yml explicitly delegates a URL as a definitive metadata source? (Meaning (probably) that values for any META.yml fields are superseded if they appear in the online query result.) Provided a machine-discoverable web API, multiple implementations could co-exist. And there's also the consideration that some data should/could be per-author rather than per-dist: http://www.nntp.perl.org/group/perl.qa/2007/03/msg8050.html --Eric -- Don't worry about what anybody else is going to do. The best way to predict the future is to invent it. --Alan Kay --- http://scratchcomputing.com ---