Ni ĉiuj amas Ansible, sed Ansible estas YAML. Estas multaj formatoj por agordaj dosieroj: listoj de valoroj, parametro-valoraj paroj, INI-dosieroj, YAML, JSON, XML kaj multaj aliaj. Tamen, pro pluraj kialoj el ĉiuj, YAML ofte estas konsiderita precipe malfacila. Aparte, malgraŭ ĝia refreŝiga minimumismo kaj imponaj kapabloj por labori kun hierarkiaj valoroj, la YAML-sintakso povas esti ĝena pro sia Python-simila aliro al indentado.
Se YAML kolerigas vin, vi povas—kaj vi devus! – prenu la sekvajn 10 paŝojn por redukti vian frustriĝon al akceptebla nivelo kaj enamiĝi al YAML. Kiel decas al ĉi tiu listo, niaj dek konsiletoj estos numeritaj de nulo, ni aldonos meditadon kaj spiritajn praktikojn laŭplaĉe 😉
0. Faru vian redaktilon funkcii
Ne gravas, kian tekstredaktilon vi havas, verŝajne ekzistas almenaŭ unu kromaĵo por labori kun YAML. Se vi ne havas tian, trovu kaj instalu ĝin tuj. La tempo elspezita serĉado kaj agordo pagos multfoje ĉiufoje kiam vi devos redakti YAML.
Ekzemple, redaktisto subtenas YAML defaŭlte, sed por GNU Emakso vi devos instali pliajn pakaĵojn, ekzemple, .
Emakso en YAML-reĝimo kaj montranta spacojn.
Se via plej ŝatata redaktilo ne havas YAML-reĝimon, tiam iuj el la problemoj povas esti solvitaj laborante kun la agordoj. Ekzemple, la norma GNOME tekstredaktilo Gedit ne havas YAML-reĝimon, sed defaŭlte ĝi elstarigas YAML-sintakso kaj ebligas al vi agordi laboron kun indentaĵoj:
Agordi dekontojn en Gedit.
Kromaĵo por Gedit, montras spacojn kiel punktojn, forigante ambiguaĵojn kun indentniveloj.
Alivorte, pasigu tempon lernante pri via plej ŝatata redaktilo. Eltrovu kion li aŭ lia evolukomunumo havas por oferti por labori kun YAML, kaj uzu tiujn funkciojn. Vi certe ne bedaŭros ĝin.
1. Uzu linter
Ideale, programlingvoj kaj marklingvoj uzas antaŭvideblan sintakson. Komputiloj lertas pri antaŭvidebleco, tial la koncepto de . Se en la 40 jaroj de sia ekzisto ĝi preterpasis vin kaj vi ankoraŭ ne uzas YAML linter, tiam estas tempo provi yamllint.
Instali Vi povas uzi la norman Linuksan pakadministradon. Ekzemple, en 8 aŭ ĝi fariĝas jene:
$ sudo dnf install yamllint
Tiam vi simple rulu yamllint, pasante al ĝi la YAML-dosieron por kontroli. Jen kiel ĝi aspektas se vi pasas dosieron kun eraro al la linter:
$ yamllint errorprone.yaml
errorprone.yaml
23:10 error syntax error: mapping values are not allowed here
23:11 error trailing spaces (trailing-spaces)
La nombroj maldekstre ne estas la tempo, sed la koordinatoj de la eraro: numero de vico kaj kolumno. La priskribo de la eraro eble nenion diras al vi, sed vi scias precize kie ĝi estas. Nur rigardu ĉi tiun lokon en la kodo, kaj plej verŝajne ĉio fariĝos klara.
Kiam yamllint trovas neniujn erarojn en dosiero, nenio estas presita al la ekrano. Se tia silento timigas vin kaj vi volas iom pli da sugestoj, tiam vi povas ruli la linter per la kondiĉa eĥa komando per duobla signo (&&), jene:
$ yamllint perfect.yaml && echo "OK"
OK
En POSIX, duobla ampersand pafas se kaj nur se la antaŭa komando redonas 0. Kaj yamllint nur redonas la nombron da eraroj trovitaj, tial ĉi tiu tuta kondiĉa konstruo funkcias.
2. Skribu en Python, ne YAML
Se YAML vere kolerigas vin, simple ne skribu en ĝi, laŭvorte. Okazas, ke YAML estas la sola formato, kiun la aplikaĵo komprenas. Sed eĉ en ĉi tiu kazo, ne necesas krei YAML-dosieron. Skribu pri tio, kion vi ŝatas kaj poste konvertu. Ekzemple, ekzistas bonega biblioteko por Python kaj du konvertaj metodoj: memkonverto kaj konvertiĝo per skriptoj.
Memkonverto
En ĉi tiu kazo, la datumdosiero ankaŭ estas Python-skripto, kiu generas YAML. Ĉi tiu metodo plej taŭgas por malgrandaj datumaj aroj. Vi simple skribas la JSON-datumojn en Python-variablon, antaŭparolas ĝin per importdirektivo, kaj ĉe la fino de la dosiero aldonu tri liniojn por efektivigi la eligon.
#!/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
Nun ni rulas ĉi tiun dosieron en Python kaj ricevas la output.yaml-dosieron:
$ python3 ./example.json
$ cat output.yaml
glossary:
GlossDiv:
GlossList:
GlossEntry:
Abbrev: ISO 8879:1986
Acronym: SGML
GlossDef:
GlossSeeAlso: [GML, XML]
para: A meta-markup language, used to create markup languages such as DocBook.
GlossSee: markup
GlossTerm: Standard Generalized Markup Language
ID: SGML
SortAs: SGML
title: S
title: example glossary
Ĉi tio estas perfekte valida YAML, sed yamllint avertos vin, ke ĝi ne komenciĝas per -. Nu, ĉi tio povas esti facile korektita permane aŭ iomete modifita en la Python-skripto.
Konvertiĝo per skriptoj
En ĉi tiu kazo, ni unue skribas en JSON, kaj poste rulas la konvertilon kiel aparta Python-skripto, kiu produktas YAML kiel eligo. Kompare kun la antaŭa metodo, ĉi tiu metodo pli bone skalas, ĉar la konvertiĝo estas aparta de la datumoj.
Unue, ni kreu JSON-dosieron example.json, ekzemple, vi povas preni ĝin de :
{
"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"
}
}
}
}
}
Tiam ni kreos simplan konvertilan skripton kaj konservos ĝin sub la nomo json2yaml.py. Ĉi tiu skripto importas kaj YAML kaj JSON-Python-modulojn, kaj ŝarĝas uzant-specifitan JSON-dosieron, faras la konvertiĝon kaj skribas la datumojn al la output.yaml-dosiero.
#!/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()
Konservu ĉi tiun skripton en la sistema vojo kaj rulu ĝin laŭbezone:
$ ~/bin/json2yaml.py example.json
3. Analizu multe kaj ofte
Kelkfoje estas utile rigardi problemon el alia angulo. Se vi havas problemojn por reprezenti la rilatojn inter viaj datumoj en YAML, vi povas provizore transformi ĝin en ion pli konatan.
Ekzemple, se vi komfortas labori kun vortarlistoj aŭ JSON, vi povas konverti YAML al JSON per nur du komandoj en la interaga Python-ŝelo. Ni diru, ke vi havas YAML-dosieron mydata.yaml, tiam jen kiel ĝi aspektus:
$ 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': 'Good article. Could be better.'}
Vi povas trovi multajn aliajn ekzemplojn pri ĉi tiu temo. Krome, ekzistas multaj interretaj konvertiloj kaj lokaj analiziloj haveblaj. Do ne hezitu reformatigi la datumojn, kiam vi vidas en ĝi nur nekompreneblan miksaĵon.
4. Legu la specifojn
Revenante al YAML post longa paŭzo, estas utile viziti kaj relegu la specifojn (specifojn). Se vi havas malfacilaĵojn kun YAML, sed ne atingis la specifon, tiam estas tempo korekti ĉi tiun situacion. La specifoj estas surprize facile skribi, kaj la sintaksaj postuloj estas ilustritaj per granda nombro da ekzemploj en .
5. Pseŭdo-agordoj
Verkante libron aŭ artikolon, ĉiam utilas unue skizi antaŭan skizon, almenaŭ en formo de enhavtabelo. Estas same kun YAML. Plej verŝajne, vi havas ideon pri kiaj datumoj devas esti skribitaj en YAML-dosieron, sed vi ne vere komprenas kiel ligi ĝin unu kun la alia. Tial, antaŭ skulpti YAML, desegnu pseŭdo-agordon.
Pseŭdo-agordo similas al pseŭdo-kodo, kie vi ne devas zorgi pri strukturo aŭ indentaĵo, gepatro-infanaj rilatoj, heredo kaj nestado. Estas same ĉi tie: vi desegnas ripetojn de la datumoj kiam ili aperas en via kapo.
Pseŭdo-agordaj listigantaj programistoj (Martin kaj Tabitha) kaj iliaj kapabloj (programlingvoj: Python, Perl, Pascal kaj Lisp, Fortran, Erlang, respektive).
Desegninte pseŭdo-konfiguradon sur papero, zorge analizu ĝin kaj, se ĉio estas en ordo, formatu ĝin en la formo de valida YAML-dosiero.
6. La Tabs vs. Spaces Dilemo
Vi devos solvi la dilemon . Ne en tutmonda senco, sed nur je la nivelo de via organizo, aŭ almenaŭ projekto. Ne gravas ĉu tio implicas uzi post-traktadon kun sed-skripto, starigi tekstoredaktilojn sur programistoj-maŝinoj aŭ universale preni kvitancojn de strikta plenumo de la instrukcioj de la linter sub minaco de maldungo, sed ĉiuj membroj de via teamo, kiuj en unu maniero aŭ alia rilatas al YAML devas uzi nur spacojn (kiel postulas la YAML-specifo).
En iu normala tekstredaktilo, vi povas agordi aŭtomate korektajn langetojn al difinita nombro da spacoj, do la ribelo de ŝlosilaj adeptoj tab vi ne devas timi.
Kiel ĉiu malamanto de YAML bone scias, vi ne povas vidi la diferencon inter langetoj kaj spacoj sur ekrano. Kaj kiam io ne videblas, ĝi estas kutime la lasta afero, kiun homoj memoras, post kiam ili ordigis, kontrolis kaj forigis ĉiujn aliajn eblajn problemojn. Horo da tempo elspezita serĉante tabelan kurbon aŭ blokon da spacoj simple krias, ke vi urĝe bezonas krei politikon por la uzo de unu aŭ la alia, kaj poste efektivigi ferbetonan kontrolon por plenumi ĝin (ekzemple, per Git-hoko por devigi ĝin tra linter).
7. Malpli estas pli (aŭ pli estas malpli)
Iuj homoj ŝatas skribi en YAML ĉar ĝi emfazas strukturon. Samtempe ili aktive uzas indentaĵon por reliefigi blokojn de datumoj. Ĉi tio estas speco de fraŭdo por imiti markadajn lingvojn, kiuj uzas eksplicitajn limilojn.
Jen ekzemplo de tia strukturo de :
# Employee records
- martin:
name: Martin D'vloper
job: Developer
skills:
- python
- perl
- pascal
- tabitha:
name: Tabitha Bitumen
job: Developer
skills:
- lisp
- fortran
- erlang
Por iuj, ĉi tiu opcio helpas ilin ordigi la YAML-strukturon en iliaj kapoj; por aliaj, kontraŭe, ĝi iritas ilin per multaj nenecesaj, laŭ ilia opinio, indentaĵoj.
Sed se vi estas la posedanto de la YAML-dokumento kaj respondecas pri konservado de ĝi, tiam vi kaj nur vi devas difini kiel uzi indentaĵon. Se vi estas ĝenita de granda remburaĵo, tenu ĝin al la minimumo ebla laŭ la YAML-specifo. Ekzemple, la supra dosiero de la Ansible-dokumentado povas esti reverkita tiel sen ia perdo:
---
- martin:
name: Martin D'vloper
job: Developer
skills:
- python
- perl
- pascal
- tabitha:
name: Tabitha Bitumen
job: Developer
skills:
- lisp
- fortran
- erlang
8. Uzu malplenajn
Se vi konstante ripetas la samajn erarojn plenigante YAML-dosieron, estas senco enmeti ŝablonon en ĝin kiel komenton. Tiam venontfoje vi povas simple kopii ĉi tiun ŝablonon kaj enigi realajn datumojn tie, ekzemple:
---
# - <common name>:
# name: Given Surname
# job: JOB
# skills:
# - LANG
- martin:
name: Martin D'vloper
job: Developer
skills:
- python
- perl
- pascal
- tabitha:
name: Tabitha Bitumen
job: Developer
skills:
- lisp
- fortran
- erlang
9. Uzu ion alian
Se la aplikaĵo ne sufokas vin, tiam eble indas ŝanĝi la YAML al malsama formato. Kun la tempo, agordaj dosieroj povas superi sin kaj tiam estas pli bone konverti ilin en simplajn skriptojn en Lua aŭ Python.
YAML estas bonega afero, kiun multaj homoj amas pro ĝia minimumismo kaj simpleco, sed ĝi estas malproksima de la sola ilo en via arsenalo. Do foje vi povas rifuzi ĝin. Analizaj bibliotekoj estas facile troveblaj por YAML, do se vi ofertas facilajn migradajn opciojn, viaj uzantoj travivos ĉi tiun malsukceson relative sendanĝere.
Se vi ne povas malhavi YAML, tiam prenu ĉi tiujn 10 konsiletojn kaj superu vian malŝaton de YAML unufoje por ĉiam!
fonto: www.habr.com