Adjust profile manifest requirements for pfm_name and pfm_type

[homebysix]

Copying over @apizz's comments from this pull request.

One thing I did discover is that while it will fail to let me commit if I remove the pfm_type key it will notably commit just fine without a pfm_name key. It's required for top-level keys (first layer of pfm_subkeys) but not for all items in the layer below that (thinking of an array with a subkey that's a string). Not sure how difficult it would be to add this just at the layer we need, but if we could get that included as a required key that would be awesome!

[homebysix]

@apizz Just to clarify: pfm_name should be required for the first level of pfm_subkeys, but is not required deeper than that?

[apizz]

So I guess this is less nuanced than I thought. pfm_name is required for all first level subkeys from the top / root level manifest. After that, it is only for additional pfm_subkeys layers that do not have a parent preference whose pfm_type is array that a pfm_name is not required (all other pfm_types still require pfm_name). In that scenario 1 of 2 things are possible:

• we have an array of strings in which case there should be no pfm_name
• we have an array of dictionaries which similarly should have no pfm_name, but if there is yet another layer of subkeys which are not arrays or dictionaries we need pfm_name

Does that make sense?

[relgit]

I think you had an extra not sneak in there by mistake @apizz 😅

Let's go by this rule of thumb, from ProfileManifests' wiki: pfm_name is required for every preference key except immediate descendants of keys whosepfm_type is array.

[apizz]

The problem is that if we have an array of dictionaries then there will be key value pairs in the dictionary that will need pfm_name

[relgit]

If you think about it, only the dictionary is an immediate descendant of the array - not its pairs. So the need for pfm_name on these pairs is respected.