Re: Custom extensions to META.yml
Ricardo SIGNES wrote: * brian d foy [EMAIL PROTECTED] [2007-03-04T12:09:26] I'm not talking about the particular field name, but the idea that I'd want to say in META.yml Don't send me mail, or whatever setting I want. Instead of having to disable (or enable) CC for every new tool, I'd want a setting that new tools could look at without me having to change the META.yml in all of my distributions then re-uploading them all. So, for some subset of META.yml settings, you could consult the module's author settings, found at (say) $MIRROR/authors/.../RJBS/METAMETA.yml That would be on your local mirror, be it minicpan or CPAN-over-HTTP. Something like that? I feel a potentially irrational sense of dread. My gut agrees with your gut on that one... I have The Doom Song playing in the back of my mind... Adam K
Re: Custom extensions to META.yml
# from Adam Kennedy
# on Wednesday 07 March 2007 12:21 am:
This approach seems to be complicating the format for the sake the
saving a few lines of code and a few minutes of work.
You could argue that it complicates the extensions phase, but I think it
greatly simplifies the format and the transition to core. Further, it
only complicates reading if you want to be strict about checking, and
that is no more complicated than simply *accessing the data* in the
nested scheme.
The argument of putting it into the root to save some code when you
get accepted into the core assumes both that the extension WILL be
accepted into the core, and that it will always retain the same name
when it moves to the core.
It's about MULTIPLE tools being in-sync whether it is core or not. IMO,
that's better than well, we like it so we'll break 5 tools by making
it permanent or just write it in both places for a while so
everything has a chance to migrate.
It's not about saving some code when it gets accepted to core. We all
know saving code sucks.
If we're only talking about private data that will never be core, let's
just nest them under a hints/foo key and be done with it. I don't
think cc_author is such a beast.
Which is reliant on every extension author always picking unused and
ideal names, forever.
That could be an issue, but is it really worth all of this:
sub cc_author {
my $meta = shift;
if ( defined $meta-{cc_author} ) {
return $meta-{cc_author};
}
if ( defined $meta-{extensions}-{'my module
namespace'}-{cc_author} ) {
return $meta-{extentions}-{'my module
namespace'}-{cc_author};
}
return $default;
}
vs $meta-{cc_author} ? Think of the one-liners. Please.
1. There will be some public discussion before it goes core.
2. If it is in use in multiple tools before (1), then presumably there
was some public discussion first.
If we need 10 lines of code per extension, we're not doing it right. If
you're using extensions with conflicting names, tell someone about it.
The use of a module name in the extension is merely the resuse of the
uniqueness of modules for the purposes of cheaply gaining a unique
namespace in the extensions.
An alternate implementation would use the same namespace of the module
that defined the concept.
Of course. That's great for hints and private data too, but if we do
extensions with the values nested under the namespace, we might as well
forget about making them part of the core spec because migration day
will break everything.
--Eric
--
It ain't those parts of the Bible that I can't understand that
bother me, it's the parts that I do understand.
--Mark Twain
---
http://scratchcomputing.com
---
Re: Custom extensions to META.yml
Graham Barr wrote: What I think brian is saying, and I agree, is that he does not want to have to say don't send me mail N times. Where N is between 1 and, um I don't know. Haw many tools will there ever be that want to send mail back to the author and what will their names be ? So as well as having per-tool settings in META.yml there should be some global settings that all tools agree to use as a default. At that point, is it an extension anymore or a de-facto standard? Anyhow, the two desires don't seem mutually exclusive. extensions: authors: MSCHWERN: pants: 0 SKUD: pants: Skirt distributions: Acme-Ninja: hi: keeba! global: cc_author: 0 This allows per distribution, per author and defacto standard global extensions without polluting the main space with yucky X-Foo keys.
Re: Custom extensions to META.yml
Chris Dolan wrote: Personally, The best solution is to have an official policy for adding non-standard additions. X- is bad for reasons that many people have shared. I like the idea of a per-module special prefs area. To insure that collisions are impossible, how about a URI for the prefs wrapper like below (sorry, not sure if this is valid YAML) extensions: 'http://search.cpan.org/dist/CPAN-Reporter/': cc_author: 0 That will enable the extension mechanism to work for non-Perl code too. To me, that feels a little like the -moz-* CSS extensions that Mozilla and others use. I endorse this product/service/concept. That said, the biggest drawback of this whole thing is that it's just one more piece of information that module authors need to think about when writing code. Writing a good CPAN module is already a fairly hefty task. I'm not saying there's an alternative, but really what we need is the module creator's equivalent of Perl Best Practices. META.yaml is a standardized data interchange format for intersystem communication. It probably shouldn't be being written by hand, but being generated by the configure (Makefile.PL,Build.PL) script. Special additions to the META.yml for some specific case should thus ideally be implemented via some command in the configuration module. So in Module::Install for example... cc_author 0; ... would cause the above extension code to be inserted. Adam K
Re: Custom extensions to META.yml
Eric Wilhelm wrote: # from Chris Dolan # on Sunday 04 March 2007 11:44 am: To insure that collisions are impossible, how about a URI for the prefs wrapper like below (sorry, not sure if this is valid YAML) extensions: 'http://search.cpan.org/dist/CPAN-Reporter/': cc_author: 0 That prevents collisions, but makes the extensions difficult to use (long key name) and difficult to promote to official status. What's wrong with: cc_author: 0 meta-spec: ... extensions: cc_author: 'http://search.cpan.org/dist/CPAN-Reporter/' ? The problem is it's not self-contained, it requires much more additional state to be held, and far more additional checking. More things can go wrong and the implementation would thus be more complicated. And it's more wordy and more complicated that the other way Adam K
Re: Custom extensions to META.yml
I would rather just lobby for cc_author being added to the spec with a very simple binary option rather than see a whole extension system built. cc_author: 0 Or even -- in a CPAN::Reporter independent style -- something like this: cc_author: pass: 0 fail: 1 unknown: 1 na: 0 So I'm urging more laziness and impatience, less hubris. Frankly, the META.yml spec is already over-populated and polluted as it is because (I suspect) of this approach. There's been a number of keys that just got added at some point in time that are now redundant or make no sense or represented (at the time) incorrect thinking that was later corrected. The advantage of a simple extension approach is modularity. It creates an area in which we can separate the very cautious high-communications standards approach stuff from the arbitrary experiments of the CPAN community at large. And it creates a sort of DMZ and testing ground for features, before they most to the core. Adam K
Re: Custom extensions to META.yml
On 3/5/07, brian d foy [EMAIL PROTECTED] wrote: In article [EMAIL PROTECTED], Ricardo SIGNES [EMAIL PROTECTED] wrote: * brian d foy [EMAIL PROTECTED] [2007-03-04T12:09:26] I'm not talking about the particular field name, but the idea that I'd want to say in META.yml Don't send me mail, or whatever setting I want. Instead of having to disable (or enable) CC for every new tool, I'd want a setting that new tools could look at without me having to change the META.yml in all of my distributions then re-uploading them all. So, for some subset of META.yml settings, you could consult the module's author settings, found at (say) $MIRROR/authors/.../RJBS/METAMETA.yml Something like that? I feel a potentially irrational sense of dread. I'm not even sure what you mean by that, and it certainly isn't anything I'm talking about. I'm just saying that setting configuration options per tool isn't the way to handle global preferences. That's why my first suggestion was hints: test_reporter: cc_author: whatever makes sense like 0 or the map suggested by David Golden or both It means the author is giving some hints. In the specific case, they are hints for a test reporter which has some news to tell about a test run of some of the author's distributions. The author is saying in which conditions he would like to receive a cc-ed copy of the test report. Of course, CPAN::Reporter got the lead because it is one of the first modules which integrated to CPAN to do this reporting stuff. So it is fair, it defines the meaning of attributes like cc_author. Nevertheless, it is a global preference. Other test reporters could be given hints with the same part of META.yml I don't think it is hard to see that other tools may take advantage of hints provided by authors as well.
Re: Custom extensions to META.yml
* brian d foy [EMAIL PROTECTED] [2007-03-04T12:09:26] I'm not talking about the particular field name, but the idea that I'd want to say in META.yml Don't send me mail, or whatever setting I want. Instead of having to disable (or enable) CC for every new tool, I'd want a setting that new tools could look at without me having to change the META.yml in all of my distributions then re-uploading them all. So, for some subset of META.yml settings, you could consult the module's author settings, found at (say) $MIRROR/authors/.../RJBS/METAMETA.yml That would be on your local mirror, be it minicpan or CPAN-over-HTTP. Something like that? I feel a potentially irrational sense of dread. -- rjbs
Re: Custom extensions to META.yml
In article [EMAIL PROTECTED], Ricardo SIGNES [EMAIL PROTECTED] wrote: * brian d foy [EMAIL PROTECTED] [2007-03-03T13:31:15] In article [EMAIL PROTECTED], Ricardo SIGNES [EMAIL PROTECTED] wrote: extensions: CPAN::Reporter: cc_author: 0 I think in some cases this might work, but I can imagine options that I'd want, such as cc_author, that future modules or tools might use. I won't know of them a priori, but it's likely that my answer to them will be the same. If you don't know that CPAN::Reporter uses extensions/CPAN::Reporter/cc_author, you won't know that it uses cc_author, either. I'm not talking about the particular field name, but the idea that I'd want to say in META.yml Don't send me mail, or whatever setting I want. Instead of having to disable (or enable) CC for every new tool, I'd want a setting that new tools could look at without me having to change the META.yml in all of my distributions then re-uploading them all.
Re: Custom extensions to META.yml
On Mar 2, 2007, at 4:45 PM, David Golden wrote: For the META.yml spec, should anything not expressly allowed be forbidden? No. Be liberal in what you accept and conservative in what you emit. Everything is hell for back/forward compatibility. Personally, The best solution is to have an official policy for adding non-standard additions. X- is bad for reasons that many people have shared. I like the idea of a per-module special prefs area. To insure that collisions are impossible, how about a URI for the prefs wrapper like below (sorry, not sure if this is valid YAML) extensions: 'http://search.cpan.org/dist/CPAN-Reporter/': cc_author: 0 That will enable the extension mechanism to work for non-Perl code too. To me, that feels a little like the -moz-* CSS extensions that Mozilla and others use. === That said, the biggest drawback of this whole thing is that it's just one more piece of information that module authors need to think about when writing code. Writing a good CPAN module is already a fairly hefty task. I'm not saying there's an alternative, but really what we need is the module creator's equivalent of Perl Best Practices. Chris -- Chris Dolan, Equilibrious LLC, http://equilibrious.net/ Public key: http://chrisdolan.net/public.key vCard: http://chrisdolan.net/ChrisDolan.vcf
Re: Custom extensions to META.yml
# from Chris Dolan # on Sunday 04 March 2007 11:44 am: To insure that collisions are impossible, how about a URI for the prefs wrapper like below (sorry, not sure if this is valid YAML) extensions: 'http://search.cpan.org/dist/CPAN-Reporter/': cc_author: 0 That prevents collisions, but makes the extensions difficult to use (long key name) and difficult to promote to official status. What's wrong with: cc_author: 0 meta-spec: ... extensions: cc_author: 'http://search.cpan.org/dist/CPAN-Reporter/' ? --Eric -- Matter will be damaged in direct proportion to its value. --Murphy's Constant --- http://scratchcomputing.com ---
Re: Custom extensions to META.yml
A. Pagaltzis writes: * Smylers [EMAIL PROTECTED] [2007-03-02 22:55]: A. Pagaltzis writes: * Smylers [EMAIL PROTECTED] [2007-03-01 21:45]: ... how do you tell whether `bastract` is a typo or extension field? You can't. But equally you can't tell if hints: test-reporter: cc_arthur is a typo or not. (Admittedly if it's a typo for abstract then it's a particularly _bad_ typo ...) Yes, you can’t know anything about extension elements. That’s a given. But if you contain them in an extension hook and disallow arbitrary placement of extension elements, then you can at least validate the rest of the document with strict rules. Unless the mistake somebody makes is it forget whether a field is in the 'officially sanctioned' category or is an extension. I think adding a `hints` field which is a hash of hashes, where the key in `hints` acts as a namespace, is the best proposition so far. ... I still think that the 'hints' level is unnecessary: for any key in 'hints', can you imagine a situation where it's _also_ a key top-level key? Think how confusing it would be to have both 'test-reporter' and 'hints: test-reporter'. I’m not sure this would be particularly common problem? Exactly my point! If any 'hints: foo' field gets widespread use then the spec would avoid defining a clashing 'foo' field, because that would be far too confusing. So in practice a given field is only going to exist either at the top level or in 'hints'. And from a user's point of view that distinction can look quite arbitrary -- it's basically an artefact of which process somebody went through to get the field added. That doesn't seem like a useful distinction to inflict on users. The point of `hints` is simply to contain extensions such that every part of the document other than what’s under `hints` is precisely specified. There are other ways of achieving this, possibly even going further and specifying which extension fields being used. For example there could be a field 'extension-fields' which lists them (with their types?). Smylers
Re: Custom extensions to META.yml
On 3/1/07, Steve Pitchford [EMAIL PROTECTED] wrote: This seems a very pragmatic solution to a problem, however given recent posts, it seems to be a solution in search of approval - is there a meta.yml owner / committee / interest group - at least a mailing list? Well, Ken Williams maintains the spec [1] so I consider him the ultimate approver for all practical purposes. I wanted to get community reactions/suggestions/improvement and with any luck, some degree of consensus. Then I was going to send Ken a patch to the blead spec and a summary of the discussion (though he's on all these lists, too, so I assume he's following it.) In response to other questions about X-foo, I was mirroring the RFC 822 email spec, where the spec promises that X- will never conflict with any future extensions to the spec. (No promise is made about these user fields conflicting with each other, of course) The corollary is that X- entries shouldn't be flagged as being in violation of a spec, either. (E.g. by CPANTS) I wasn't recommending it, just putting it out there for consideration. I prefer the hints approach, as that makes the purpose of the additional information slightly clearer. David [1] http://module-build.sourceforge.net/META-spec-blead.html
Re: Custom extensions to META.yml
* David Golden [EMAIL PROTECTED] [2007-02-28T22:39:01] Is there a de facto standard for custom extensions to META.yml? (I didn't see one in the spec.) An example might be fields beginning with a capital letter or X-foo style extensions. E.g. Why not: extensions: CPAN::Reporter: cc_author: 0 (PLEASE let's avoid 'yes' and 'no' as booleans.) If all the extensions are under the module (or, hey, dist) that uses them, then the X-nonsense is avoided. -- rjbs
Re: Custom extensions to META.yml
A. Pagaltzis writes: * Smylers [EMAIL PROTECTED] [2007-03-01 21:45]: Can't we just start using cc-author as a field, then if it takes off get it blessed as part of the official spec? Then how do you tell whether `bastract` is a typo or extension field? You can't. But equally you can't tell if hints: test-reporter: cc_arthur is a typo or not. (Admittedly if it's a typo for abstract then it's a particularly _bad_ typo ...) I think adding a `hints` field which is a hash of hashes, where the key in `hints` acts as a namespace, is the best proposition so far. The extra name-spaces avoid clashes. But I still think that the 'hints' level is unnecessary: for any key in 'hints', can you imagine a situation where it's _also_ a key top-level key? Think how confusing it would be to have both 'test-reporter' and 'hints: test-reporter'. Smylers
Re: Custom extensions to META.yml
David Golden writes: In response to other questions about X-foo, I was mirroring the RFC 822 email spec Yeah; that's why I'm so hostile to the idea! Mail headers have X-Mailer: but User-Agent: without the X-; and X-Mailing-List: but Posted-To: and List-Id: -- from a user's point of view it's arbitrary which headers have X- and which don't, and very hard to remember. Smylers
Re: Custom extensions to META.yml
# from David Golden # on Friday 02 March 2007 02:45 pm: For the META.yml spec, should anything not expressly allowed be forbidden? If so, then any extension like this has to be explicitly added to the spec. On the positive side, it doesn't leave ambiguity for tools that work with META.yml. What about having an extensions field as part of the spec declaration, where anything listed in it is allowed? This would mean that tools which are extending the spec would not have to change the attribute name if it gets adopted as-is, and would still allow strict validation if you're into that sort of thing. --- thbbt: foo meta-spec: url: http://module-build.sourceforge.net/META-spec-v1.4.html version: 1.4 extensions: - thbbt Later, say thbbt becomes an official part of 1.5: --- thbbt: foo meta-spec: url: http://module-build.sourceforge.net/META-spec-v1.5.html version: 1.5 At that point (v1.5), thbbt is probably not allowed in 'extensions' (because as an extension, it would conflict with a now-official part of the spec.) Wait, let's make 'extensions' a hash, thus allowing you to say which (possibly competing) version of the thbbt extension you're using. meta-spec: ... extensions: thbbt: http://welikethbbt.com/a_new_meta_attribute.html So, ad-hoc extensibility which is ready-for-adoption without changing the tools, all without namespace clashes? (Concurrent usage of competing thbbt's is discouraged, but will be handled via flame-war between the thbbt'ers as needed.) --Eric -- Consumers want choice, consumers want openness. --Rob Glaser --- http://scratchcomputing.com ---
Re: Custom extensions to META.yml
* Smylers [EMAIL PROTECTED] [2007-03-02 22:55]: A. Pagaltzis writes: * Smylers [EMAIL PROTECTED] [2007-03-01 21:45]: Can't we just start using cc-author as a field, then if it takes off get it blessed as part of the official spec? Then how do you tell whether `bastract` is a typo or extension field? You can't. But equally you can't tell if hints: test-reporter: cc_arthur is a typo or not. (Admittedly if it's a typo for abstract then it's a particularly _bad_ typo ...) Yes, you can’t know anything about extension elements. That’s a given. But if you contain them in an extension hook and disallow arbitrary placement of extension elements, then you can at least validate the rest of the document with strict rules. I think adding a `hints` field which is a hash of hashes, where the key in `hints` acts as a namespace, is the best proposition so far. The extra name-spaces avoid clashes. But I still think that the 'hints' level is unnecessary: for any key in 'hints', can you imagine a situation where it's _also_ a key top-level key? Think how confusing it would be to have both 'test-reporter' and 'hints: test-reporter'. I’m not sure this would be particularly common problem? The point of `hints` is simply to contain extensions such that every part of the document other than what’s under `hints` is precisely specified. If you hoist the extension namespaces up one level, that is no longer the case: you don’t know if `bastract` is a namespace or a typo. (Same problem as with simply putting extension elements anyplace.) Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Custom extensions to META.yml
On 3/1/07, David Golden [EMAIL PROTECTED] wrote: I've had some requests for a mechanism for module authors to indicate whether or not they want to be copied on module test emails generated by CPAN::Reporter (particularly for passing reports). This seems like the kind of thing that should go in the module META.yml. I really like this idea. Is there a de facto standard for custom extensions to META.yml? (I didn't see one in the spec.) An example might be fields beginning with a capital letter or X-foo style extensions. E.g. I don't think there is a standard for these extensions to META.yml, but I am convinced there must be sensible ways to do it when we need them. Note that it precludes the idea of a complete and closed schema for the META.yml specification. X-cc-author: no Alternatively, what would people think about adding a field in META.yml like notes for this kind of extra information. E.g.: notes: cc_author: no My suggestion would be to have a section 'hints' in META.yml (that would look like the 'notes' you suggested, only with a name which indicates the section contents is actually suggestions rather than rules to be followed). This section could be subdivided into tools -- meaning the author is giving hints to various tools involved in the processing of distributions. These tools could be named generically. For instance, 'test_reporter' could be used in CPAN::Reporter case. Why not the module name itself? So that someone else could implement its test reporter and use the same information without being ashamed because that information was meant for some other piece of code ;-) This way, the section to be added to META.yml would be hints: test_reporter: cc_author: no Of course, we would like to see all the variants we grow used to, like cc_author: no cc_author: yes cc_author: fail cc_author: ok # this author likes to receive only good news Thanks in advance for your thoughts. Thank you. Adriano Ferreira.
Re: Custom extensions to META.yml
On 3/1/07, David Golden [EMAIL PROTECTED] wrote: I've had some requests for a mechanism for module authors to indicate whether or not they want to be copied on module test emails generated by CPAN::Reporter (particularly for passing reports). This seems like the kind of thing that should go in the module META.yml. Is there a de facto standard for custom extensions to META.yml? (I didn't see one in the spec.) An example might be fields beginning with a capital letter or X-foo style extensions. E.g. X-cc-author: no Alternatively, what would people think about adding a field in META.yml like notes for this kind of extra information. E.g.: notes: cc_author: no I would prefer the second option because it is more modular. However, there should be a way to add things to it easily when preparing the META.yml. Regards, Shlomi Fish Thanks in advance for your thoughts. David -- -- Shlomi Fish http://www.shlomifish.org/ If his programming is anything like his philosophising, he would find 10 imaginary bugs in the Hello World program.
Re: Custom extensions to META.yml
On 3/1/07, Adriano Ferreira [EMAIL PROTECTED] wrote: My suggestion would be to have a section 'hints' in META.yml (that I think that's an excellent name for the section I proposed. Of course, we would like to see all the variants we grow used to, like cc_author: no cc_author: yes cc_author: fail cc_author: ok # this author likes to receive only good news My thiought was that it would take the same specification as CPAN::Reporter uses in the configuration file -- though quoting would be required for the advanced forms: cc_author: 'fail/na/unknown:yes pass:no' David
Custom extensions to META.yml
I've had some requests for a mechanism for module authors to indicate whether or not they want to be copied on module test emails generated by CPAN::Reporter (particularly for passing reports). This seems like the kind of thing that should go in the module META.yml. Is there a de facto standard for custom extensions to META.yml? (I didn't see one in the spec.) An example might be fields beginning with a capital letter or X-foo style extensions. E.g. X-cc-author: no Alternatively, what would people think about adding a field in META.yml like notes for this kind of extra information. E.g.: notes: cc_author: no Thanks in advance for your thoughts. David
Re: Custom extensions to META.yml
David Golden writes: Is there a de facto standard for custom extensions to META.yml? (I didn't see one in the spec.) An example might be fields beginning with a capital letter or X-foo style extensions. E.g. X-cc-author: no Does putting X- in front of such fields really help? X- isn't really a namespace; having 2 people separately inventing the X-Hair-Colour field isn't any better than them clashing over Hair-Colour. And if your X-cc-author field takes off can you really envisage a separate CC-Author field being created? Having them both in existence would be really confusing. So in practice all the X- achieves is making users have to remember which field names have an X- in front of them and which don't! Alternatively, what would people think about adding a field in META.yml like notes for this kind of extra information. E.g.: notes: cc_author: no Similar kind of problem: notes is very generic (like other or misc), such that it's arbitrary which is a 'proper' field and which is a 'notes' field. Can't we just start using cc-author as a field, then if it takes off get it blessed as part of the official spec? Smylers
Re: Custom extensions to META.yml
* Smylers [EMAIL PROTECTED] [2007-03-01 21:45]: Can't we just start using cc-author as a field, then if it takes off get it blessed as part of the official spec? Then how do you tell whether `bastract` is a typo or extension field? I think adding a `hints` field which is a hash of hashes, where the key in `hints` acts as a namespace, is the best proposition so far. This would also reduce the following problem to near irrelevance: Does putting X- in front of such fields really help? X- isn't really a namespace; having 2 people separately inventing the X-Hair-Colour field isn't any better than them clashing over Hair-Colour. If `notes` is a hash of hashes, then the only clash potential is among keys in the upper level hash, which should be about as clash-prone as distro names on the CPAN – admittedly not an inherently collision-free system, but one that works well enough in practice. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Custom extensions to META.yml
Following David Goldens' observations, Adriano Ferreira wrote: This way, the section to be added to META.yml would be hints: test_reporter: cc_author: no This seems a very pragmatic solution to a problem, however given recent posts, it seems to be a solution in search of approval - is there a meta.yml owner / committee / interest group - at least a mailing list? Steve
