Mochitests should use ManifestDestiny manifests for fine-grained control of what is run on what platform, etc.

Not sure if this is the best forum for it, but we need to figure out how we want to deal with associated files. E.g. if resources are required beyond the test file, how to deal with that? A simple solution would be to have a special `resources` key that lists files that the test needs, e.g.: [mytest.py] skip-if = os == 'win' resources = css/style.css css/lack-of-style.css If we don't use spaces in in-tree files (which I believe we don't) then spaces can be a separator here. (Note also that python .ini files allow multiple lines for longer values.) Paths are unix-style paths (already the manifest norm) which, if relative, are relative to the manifest. For e.g. copy operations, you would gather all of the resources as a set. If manifestdestiny-side functionality was required, my current inclination would be to have a class, ResourceManifest, that would inherit from ManifestParser and of which TestManifest would be a child. Note that the above is just a back-of-the-envelope idea. If other people have ideas, I'm certainly not attached to the above.

I think the general concept is great. Not sure if we should call it resources, but I don't have a better term. What if a file has a space in it?

(In reply to Joel Maher (:jmaher) from comment #2) > I think the general concept is great. Not sure if we should call it > resources, but I don't have a better term. What if a file has a space in it? Damn, I was hoping no one would ask that because that mandates that I actually respond to the whole issue! So the short answer is for existing stuff mozilla *mostly though certainly certainly not exclusively* use either space-separated or comma-separated for strings to be parsed as sequences. AFAIK, there is no stated convention here and opinion is divided; the comma-separated people seem louder, but I have no idea if there's actually a preference. Sometimes one is used over the other for deducible reasons: for a given situation, one or the other may occur more or...; but often it is for asserted reasons without data to back it up. For the filename issue, both spaces and commas are allowed in file-names. I vaguely recall a few issues where spaces were specifically removed from filenames, but can't recall the details. I don't know or care to grep if there are any files in m-c or elsewhere currently with spaces or commas in them. Probably a quick ask on #developers would resolve the ad hoc conventionality better that I could guess at. Are spaces more common in filenames than commas? Damned if I know. There are very few (if any?) characters actually not allowed in filenames. An alternate scheme would be to either - make the value definition for lists more explicit (how?) - use e.g. urlquote.unescape on values to get their true nature - improve the parser (how?) - use keys for this (um, ugly) - use real CSV So I'll call it an open issue. There are no easy answers. Frankly I prefer spaces as separators for this use-case because str.split() is more intent -> manifestation v [i.strip() for i in str.strip(',').split(',')] or the like

I am fine assuming we use the ' ' as a delimiter. I don't believe we have any files in m-c that use it right now.

Can we have a separate section for resources and have each resource on its own line? Is there a case where we want to distinguish a resource tied to a specific test from "shared" resources?

(In reply to Gregory Szorc [:gps] from comment #5) > Can we have a separate section for resources and have each resource on its > own line? Can? Yes. Should? Perhaps...perhaps not. I would be hesitant to introduce this as a section. If a separate list was desired, I'd be much more inclined to a whole manifest. My conceptual disinclination towards a section of resources is two-fold: 1. Tracking resources at the manifest level does not indicate which resources are needed for which test. You'll get too much. It'd be really nice to know what resources a particular test required, such that if you moved it around or what not you know what you need for that test. (This is what I sometimes call the soup principle: if you have ingredients, they're easy to mix; once mixed, they are difficult to separate.) Ultimately, IMHO, a "test" is the atomic unit of stuff-ness; whatever "molecule" (directory, manifest, etc.) it may be a part of is ephemeral. 2. Currently, a test manifest is a manifest of just tests. While there's no problem of having a mixed manifest, again, once you go from a list of one type of thing to multiple types of things, you lose a class of things you can easily do to i.e. just tests. Technically, I hesitate because adding a special resource section requires a bit of thinking. Let's say we have [:resources:] as a list of resources. How do you use this? Is this baked into ManifestDestiny? In this case, the correct approach is a mapping of special sections -> handlers (e.g. [include:*] should match and https://github.com/mozilla/mozbase/blob/master/manifestdestiny/manifestparser/manifestparser.py#L409 rewritten with that in mind). How is it used? Etc. I dunno...just feels wrong, a bunch of one offs, etc no matter how you slice it. Also, let's say you have e.g. [:resources:].... What goes it it? The file names with no values? That also seems...well, perhaps ill-suited to the data format. Conceivably, [DEFAULTS] could be leveraged here to some end (although depending on what is desired we may want code changes for that). To repeat, I am not particularly for the `resources = ...` as a key model. But I'm fairly hesitant on resources as a section. resources as a separate manifest I am fine with. I'm happy to help spec this out or just watch if others have stronger opinions > Is there a case where we want to distinguish a resource tied to a > specific test from "shared" resources?