В 2019 году я написал WSLRUN Инструмент в качестве доказательства концепции для структуры тестирования (то есть для Git Hooks, локального тестирования и т. Д.) CLI, которая использовала подсистему Windows для Linux (WSL). Я разработал его, чтобы руководствоваться файлом json, как так:
{
"name": "PS Test",
"description": "Tests building in multiple environments",
"pullPolicy": "Never",
"ciMode": "False",
"stages": [
{
"image": "AlpineDub",
"name": "Build on distro with a passing job",
"steps": [
"sudo apk --update add musl-dev",
"env CGO_ENABLED=1 GOOS=linux GOARCH=amd64 go build -v -x -o package-amd64-alpine"
]
},
{
"image": "UbuntuDub",
"name": "Build on distro I know will fail",
"steps": [
"GOOS=linux GOARCH=amd64 go build -v -x -o package-amd64-ubuntu"
]
},
{
"image": "AlpineLub",
"name": "Build on image I know doesn't exist",
"steps": [
"env GOOS=linux GOARCH=amd64 go build -v -x -o package-amd64-alpine"
]
}
]
}
Где этапы это просто вложенный объект, содержащий WSL Distro ( Image ) для выполнения соответствующего шаги (Команды, которые будут выполнены в среде WSL).
Тем не менее, я не всегда хочу писать JSON вручную, и хотя его легко генерируется автоматизацией, что делает его отличным форматом для передачи этой информации другой автоматизированной системе (например, рабочий процесс CI), я хотел поддержать Yaml как Ну, что было значительно легче для меня вручную. В этом случае вышеупомянутый JSON стал:
-------- name: PS Test description: Tests building in multiple environments pullPolicy: Never ciMode: 'False' stages: - image: AlpineDub name: Build on distro with a passing job steps: - sudo apk --update add musl-dev - env CGO_ENABLED=1 GOOS=linux GOARCH=amd64 go build -v -x -o package-amd64-alpine - image: UbuntuDub name: Build on distro I know will fail steps: - GOOS=linux GOARCH=amd64 go build -v -x -o package-amd64-ubuntu - image: AlpineLub name: Build on image I know doesn't exist steps: - GOOS=linux GOARCH=amd64 go build -v -x -o package-amd64-alpine
Наличие моей ручки инструмента CLI, это было исключительно тривиальным для достижения: Python pyyaml У пакета есть метод, safe_load который можно использовать для прочтения JSON, либо, для наших целей, визуализируется YAML для возврата в качестве JSON.
В этом случае WSLRUN Инструмент принимает аргумент, например:
wslrun --pipeline config.json
или же
wslrun --pipeline config.yaml
и в обоих случаях этот файл читается и передается в такую функцию:
def manifestRead(manifestPath):
try:
with open(manifestPath, "rt") as manifest_json:
manifest = yaml.safe_load(manifest_json)
return manifest
except OSError as e:
return e
Если Manifestpath можно прочитать в строке ( manifest_json ) и, сами, читать как действительный yaml (или уже действителен JSON), safe_load Функция вернет этот объект как Манифест , который остальная часть потока CLI будет работать, как описано выше.
Преимущество такой реализации такая: даже если вы предоставляете файл JSON, она выступает в качестве проверки достоверности контента, но также и способ предоставить несколько форматов для пользователей для записи конфигураций, оставаясь сравнительно низкоэффективными И все же эффективный способ сделать это.
Оригинал: “https://dev.to/jmarhee/using-pyyaml-to-support-yaml-and-json-configuration-files-in-your-cli-tools-1694”