handling current datatypes when rewriting YAML metadata

About the YAML format, I'm wondering how to best support things like _buildjni and gradle, which can be both boolean or lists. In YAML, yes/no/true/false are keywords that make booleans. So this would be a boolean:

  buildjni: yes

vs these, which are both strings:

  buildjni: "yes"
  buildjni: "ndk-build CUSTOM_VAR=foo"

though with YAML, this would also be a string:

  buildjni: ndk-build CUSTOM_VAR=foo

Looking at all of the gradle= lines in fdroiddata, I think the YAML input can support TYPE_LIST fields as boolean, string, or list of strings. The question is whether rewritemeta should always output a list of strings, or whether the simplest data type should be the canonical:

• "yes" would always be rewritten as a boolean
• forFDroid would always rewritten as a string
• "noMaps,noAnalytics,forFDroid" would always be written as a list of strings

@mvdan @krt @est @xinxinxinxinxin

Another example here would be versionCode, which would need to be an explicit field in YAML. That should ultimately be an integer type. I think this case is clearer, it should read in both integers and strings, but then rewrite always as integers.

YAML is basically duck-typing like Python, so this would be pretty automatic. A number without quotes will automatically become an number type, while quoting it will make it a string:

  versionCode: 123
  versionCode: "234"

Remember that version codes can be in hex (I think).

yeah, they can be in hex. Its pretty rare but we should support that I suppose. I'm thinking of just feeding any string from versionCode to a python string-to-int converter, so it should handle that.

Frankly, I dont really care and actually I have little knoledge what would be "better" (for whatever measurement scale of "better" we use). Arguing from what makes sense to me:

• versioncode should always be an integer (internally), as its supposed to be. Updatecheck, import, verification etc. should convert any read representation to decimal system. There should not be a hex representation within the metadata.

• Looking at what buildjni is used atm, it should be a list of directories, so instead of buildjni=yes this might bebuildjni=. (or whatever default directory is). I havent seen any ndk-build stuff there, neithe rany vars... but the latter might be needed one day.

• I dont see a point in having gradle= boolean either.

I like the idea of eliminating the booleans from gradle=, buildjni=, etc. as long as we're not making handling edge cases difficult. It would make things conceptually simpler. In terms of the gradle boolean, we could say that if the gradle files are present in the source code, then it defaults to gradle with the default build flavor. Then we don't need gradle=yes. Then that can always be overridden with build=

I do think that these fields should support both strings and lists, so that you can do buildjni: src/main/jni without having to make it a YAML list. buildjni= could also follow the gradle detection pattern to set a default. If Android Studio and/or gradle has a default location for the JNI files, we can use that to auto-set buildjni=yes.

We should probably make this consistent. These are all of the build fields that currently allow boolean/string/list in the txt format:

• antcommands
• buildjni
• extlibs
• gradle
• gradleprops
• patch
• preassemble
• rm
• scandelete
• scanignore
• srclibs
• update

Based on fdroiddata, these are the fields that are sometimes set to yes:

• buildjni
• gradle
• scandelete

That leaves just scandelete. How would we handle things if there is no scandelete=yes?

FYI, here's the script I used to do this survey: for f in antcommands buildjni extlibs gradle gradleprops patch preassemble rm scandelete scanignore srclibs update; do echo $f; grep ${f}= *.txt | cut -d : -f 2-222| sed 's,^\s*,,' | sort -u;done|less

assigned to @uniqx

added yaml label

changed milestone to %1.0

We can close this issue because it was fixed with: !263 (merged)

closed