Vi elsker alle Ansible, men Ansible er YAML. Det finnes mange formater for konfigurasjonsfiler: verdilister, nøkkel-verdi-par, INI-filer, YAML, JSON, XML og mange andre. Men av flere grunner anses YAML ofte for å være spesielt problematisk. Spesielt, til tross for dens friske minimalistiske stil og imponerende evner til å håndtere hierarkiske verdier, kan YAMLs syntaks irritere med sin Python-lignende tilnærming til innrykk.

Hvis YAML plager deg, kan du – og bør! – ta de 10 følgende stegene for å redusere irritasjonen din til et akseptabelt nivå og lære å elske YAML. Som en ekte liste vil våre ti tips begynne på null, og meditasjon og åndelige praksiser kan legges til etter ønske 😉
0. Få redaktøren din til å fungere
Uansett hvilken tekstredigerer du har, finnes det forhåpentligvis minst én plugin for å jobbe med YAML. Hvis ikke, finn og installer en med en gang. Tiden brukt på å lete etter og konfigurere dette, vil betale seg mange ganger hver gang du må redigere YAML.
For eksempel støtter redaktøren YAML som standard, mens GNU Emacs krever installasjon av ekstra pakker, som for eksempel .

Emacs i YAML-modus og viser mellomrom.
Hvis favorittredaktøren din ikke har YAML-modus, kan du løse noen problemer ved å leke med innstillingene. For eksempel har GNOME sin standard tekstredigerer Gedit ikke YAML-modus, men den fremhever synlig syntaks for YAML og lar deg justere innrykking:

Innstilling av innrykk i Gedit.
Og pluginen for Gedit viser mellomrom som prikker, som fjerner tvil om nivåene av innrykk.
Med andre ord, bruk litt tid på å lære redaktøren din. Finn ut hva den eller utviklerfellesskapet tilbyr for å jobbe med YAML, og bruk de mulighetene. Du kommer ikke til å angre på det.
1. Bruk en linter
Ideelt sett bruker programmeringsspråk og markup-språk en forutsigbar syntaks. Datamaskiner håndterer forutsigbarhet godt, så allerede i 1978 ble konseptet skapt. Hvis dette konseptet har gått deg forbi i løpet av de 40 årene, og du fortsatt ikke bruker en YAML-linter, er det på høy tid å prøve yamllint.
Installer kan gjøres med den innebygde pakkehanteren for Linux. For eksempel i 8 eller gjør man det slik:
$ sudo dnf install yamllint
Deretter kjører du bare yamllint, og gir den YAML-filen som skal sjekkes. Slik ser det ut hvis du gir linteren en fil med feil:
$ yamllint errorprone.yaml
errorprone.yaml
23:10 error syntaksfeil: mapping verdier er ikke tillatt her
23:11 error trailende mellomrom (trailing-spaces)
Tallene til venstre er ikke tid, men koordinater for feilen: linjenummer og kolonnenummer. Feilbeskrivelsen gir deg kanskje ikke mye informasjon, men du vet eksakt hvor den er. Bare se på stedet i koden, og så blir det mest sannsynlig klart.
Når yamllint ikke finner feil i filen, vises det ingenting på skjermen. Hvis du er bekymret for det stillheten gir, og ønsker litt mer tilbakemelding, kan du kjøre linteren med en betinget kommando echo gjennom dobbeltampersand (&&), slik:
$ yamllint perfect.yaml && echo "OK"
OK
I POSIX aktiveres dobbeltampersand da og bare da når den foresgående kommandoen returnerer 0. Og yamllint returnerer nettopp antallet funnet feil, så hele denne betingede konstruksjonen fungerer.
2. Skriv i Python, ikke i YAML
Hvis du virkelig er lei av YAML, trenger du ikke å skrive i det, bokstavelig talt. Noen ganger er YAML den eneste formatet som forstås av applikasjonen. Men selv da er det ikke nødvendig å lage en YAML-fil. Skriv i det du liker, og konverter deretter. For Python finnes det et utmerket bibliotek og faktisk to måter å konvertere på: selvkonvertering og konvertering via skript.
Selvkonvertering
I dette tilfellet er datafilen også et Python-skript som genererer YAML. Denne metoden er best egnet for små datasett. Du skriver bare JSON-dataene inn i en Python-variabel, innleder dette med en import-direktiv, og til slutt i filen legger du til tre linjer for å skrive ut.
#!/usr/bin/python3
import yaml
d={
"glossary": {
"title": "example glossary",
"GlossDiv": {
"title": "S",
"GlossList": {
"GlossEntry": {
"ID": "SGML",
"SortAs": "SGML",
"GlossTerm": "Standard Generalized Markup Language",
"Acronym": "SGML",
"Abbrev": "ISO 8879:1986",
"GlossDef": {
"para": "A meta-markup language, used to create markup languages such as DocBook.",
"GlossSeeAlso": ["GML", "XML"]
},
"GlossSee": "markup"
}
}
}
}
}
f=open('output.yaml','w')
f.write(yaml.dump(d))
f.close
Nå kjører vi denne filen i Python, og ut får vi output.yaml-filen:
$ python3 .\/example.json
$ cat output.yaml
glossary:
GlossDiv:
GlossList:
GlossEntry:
Abbrev: ISO 8879:1986
Acronym: SGML
GlossDef:
GlossSeeAlso: [GML, XML]
para: Et meta-markup-språk, som brukes til å lage markup-språk som DocBook.
GlossSee: markup
GlossTerm: Standard Generalized Markup Language
ID: SGML
SortAs: SGML
title: S
title: eksempel ordliste
Dette er helt korrekt YAML, men yamllint vil gi en advarsel om at den ikke begynner med —. Vel, dette kan enkelt rettes manuelt eller litt justeres i Python-skriptet.
Konvertering via skript
I dette tilfellet skriver vi først i JSON, og deretter kjører vi en konverterer som et eget Python-skript, som gir YAML som utdata. I motsetning til den forrige metoden, skalerer denne bedre, siden konverteringen er adskilt fra dataene.
Først må vi opprette en JSON-fil example.json, som for eksempel kan hentes fra :
{
"glossary": {
"title": "example glossary",
"GlossDiv": {
"title": "S",
"GlossList": {
"GlossEntry": {
"ID": "SGML",
"SortAs": "SGML",
"GlossTerm": "Standard Generalized Markup Language",
"Acronym": "SGML",
"Abbrev": "ISO 8879:1986",
"GlossDef": {
"para": "Et meta-markup-språk som brukes til å lage markup-språk som DocBook.",
"GlossSeeAlso": ["GML", "XML"]
},
"GlossSee": "markup"
}
}
}
}
}
Deretter lager vi et enkelt konverteringsskript og lagrer det som json2yaml.py. Dette skriptet importerer begge modulene — YAML og JSON i Python, og laster den brukerspesifiserte JSON-filen, utfører konverteringen og skriver dataene til output.yaml-filen.
#!/usr/bin/python3
import yaml
import sys
import json
OUT=open('output.yaml','w')
IN=open(sys.argv[1], 'r')
JSON = json.load(IN)
IN.close()
yaml.dump(JSON, OUT)
OUT.close()
Lagre dette skriptet i systemets sti og kjør det etter behov:
$ ~/bin/json2yaml.py example.json
3. Pars flere og ofte
Noen ganger kan det være nyttig å se problemet fra en annen vinkel. Hvis det er vanskelig å forstå sammenhengen mellom dataene i YAML, kan de midlertidig konverteres til noe mer kjent.
For eksempel, hvis du foretrekker å jobbe med ordbokslisten eller JSON, kan YAML konverteres til JSON med bare to kommandoer i Python-interaktivt skall. Anta at du har en YAML-fil mydata.yaml, her er hvordan det ville se ut:
$ python3
>>> f=open('mydata.yaml','r')
>>> yaml.load(f)
{'document': 34843, 'date': datetime.date(2019, 5, 23), 'bill-to': {'given': 'Seth', 'family': 'Kenlon', 'address': {'street': '51b Mornington Roadn', 'city': 'Brooklyn', 'state': 'Wellington', 'postal': 6021, 'country': 'NZ'}}, 'words': 938, 'comments': 'God artikkel. Kunne vært bedre.'}
Det finnes mange andre eksempler på dette emnet. I tillegg er det mange online-konverterere og lokale parserver tilgjengelig. Så ikke nøl med å omformaterere data når du ser dem som en uforståelig blanding.
4. Les spesifikasjoner
Når du vender tilbake til YAML etter en lang pause, kan det være nyttig å besøke og lese spesifikasjonene på nytt. Hvis du har hatt vanskeligheter med YAML, men ikke har fått tid til å se på spesifikasjonen, er det på høy tid å rette opp i dette. Spesifikasjonene er overraskende lettfattelige, og reglene for syntaks illustreres med et stort antall eksempler i .
5. Pseudokonfigurer
Når du skriver en bok eller artikkel, er det alltid nyttig å lage en preliminær plan, i det minste i form av et innholdsfortegnelse. Det samme gjelder YAML. Du har sannsynligvis en idé om hvilke data som skal skrives i YAML-filen, men forstår ikke helt hvordan du knytter dem sammen. Derfor, før du begynner å lage YAML, tegn et pseudokonfigurasjon.
Pseudokonfigurasjonen ligner på pseudokode, hvor du ikke trenger å bekymre deg for struktur eller innrykk, forholdet mellom 'forelder-barne', arv og innkapsling. Her tegner du datasykluser etter hvert som de dukker opp i hodet ditt.

Pseudokonfigurasjon med en opplisting av programmerere (Martin og Tabitha) og deres ferdigheter (programmeringsspråk: Python, Perl, Pascal og Lisp, Fortran, Erlang, henholdsvis).
Etter å ha tegnet pseudokonfigurasjonen på papir, analyser den nøye, og hvis alt ser bra ut, formater det som en gyldig YAML-fil.
6. Dilemmaet 'tabulering eller mellomrom'
Du må løse dilemaet . Ikke i global forstand, men bare på nivået med din organisasjon, eller minst prosjektet. Det spiller ingen rolle om du bruker post-prosessering med sed-skript, konfigurerer tekstredigerere på programmerernes maskiner, eller om hele teamet skriver under på strenge retningslinjer fra linteren under trussel om oppsigelse, alle medlemmer av teamet ditt som på en eller annen måte berører YAML, må uten unntak bruke mellomrom (som spesifikasjonen for YAML krever).
I enhver normal tekstredigerer kan du konfigurere autoudskiftning av tabulering til et angitt antall mellomrom, så det er ingen grunn til å frykte opprøret fra tilhengerne av tasten Tab kan ikke fryktes.
Som det er velkjent av enhver YAML-hater, er det ingen synlig forskjell mellom tabulering og mellomrom på skjermen. Når noe ikke er synlig, husker folk det vanligvis sist, etter å ha behandlet, sjekket og utelukket alle andre mulige problemer. En time kastet bort på å lete etter en feil tabulering eller en blokk med mellomrom, roper etter at du umiddelbart bør lage en politikk for bruk av det ene eller det andre, og deretter implementere en solid sjekk for overholdelse (for eksempel via en Git-hook for å tvinge en kjøring gjennom linteren).
7. Bedre mindre, men bedre (eller mer – det er mindre)
Noen mennesker liker å skrive i YAML, da det fremhever strukturen. De bruker aktivt innrykk for å skille datablokker. Dette er en slags juks for å imitere markup-språk som bruker tydelige separatorer.
Her er et eksempel på slik struktur fra :
# Employee records
- martin:
name: Martin D'vloper
job: Developer
skills:
- python
- perl
- pascal
- tabitha:
name: Tabitha Bitumen
job: Developer
skills:
- lisp
- fortran
- erlang
For noen hjelper denne varianten dem med å organisere YAML-strukturen, mens andre er irritert over det de anser som unødvendige innrykk.
Men hvis du er eier av en YAML-dokument og ansvarlig for vedlikeholdet, så er det kun du som skal bestemme hvordan innrykkene skal brukes. Hvis store innrykk irriterer deg, reduser dem til et minimum som er mulig i henhold til YAML-spesifikasjonen. For eksempel kan den ovennevnte filen fra Ansible-dokumentasjonen uten tap skrives slik:
---
- martin:
name: Martin D'vloper
job: Developer
skills:
- python
- perl
- pascal
- tabitha:
name: Tabitha Bitumen
job: Developer
skills:
- lisp
- fortran
- erlang
8. Bruk maler
Hvis du stadig gjentar de samme feilene når du fyller ut YAML-filen, kan det være lurt å sette inn en mal i form av en kommentar. Da kan du enkelt kopiere denne malen neste gang og fylle inn de faktiske dataene, for eksempel:
---
# - <common name>:
# name: Fornavn Etternavn
# job: JOB
# skills:
# - SPRÅK
- martin:
name: Martin D'vloper
job: Developer
skills:
- python
- perl
- pascal
- tabitha:
name: Tabitha Bitumen
job: Developer
skills:
- lisp
- fortran
- erlang
9. Bruk noe annet
Hvis applikasjonen ikke holder deg fast, kan det være lurt å bytte fra YAML til et annet format. Over tid kan konfigurasjonsfiler bli uegnet, og da er det bedre å konvertere dem til enkle skript i Lua eller Python.
YAML er et glimrende verktøy som mange liker for sitt minimalistisk uttrykk og enkelhet, men det er langt fra det eneste verktøyet i arsenalet ditt. Så noen ganger kan du fint gå bort fra det. Det er enkelt å finne parse-biblioteker for YAML, så hvis du foreslår enkle migrasjonsalternativer, vil brukerne dine forholde seg til dette klart og smertefritt.
Men hvis du ikke kan unngå YAML, så ta til deg disse 10 tipsene og overvinn din aversjon mot YAML en gang for alle!
Kilde: habr.com
