It is nice if we support more extension for manifest, like
I am going to look for supporting yaml. Best option for this types files. Mainly for supporting block chomping and other advantages (#2609)
It should not be so hard.
parse_json like parse with arguments -Yaml -Json with default fallbackConvertFrom-Yaml work exactly like ConvertFrom-Json.ConvertToPrettyYaml.writeManifest with extension parameter and then lines like: $json | ConvertToPrettyJson | WriteAllLines be extracted into that functionparse_json -> Get-Manifest { switch (extension) { ... default: _parseJson }Set-Manifest Path Content::WriteAllLinesCopy-Item (manifest_path $app $bucket) "$dir\manifest.json" -> (parse_manifest (manifest_path $app $bucket))[ ] Tests
bin\*Scoop-Format-Manifest.Tests.ps1 -> Scoop-Format-Manifest.json.Tests.ps1Scoop-Format-Manifest.yml.Tests.ps1Tests
Create bucket YAMLs in $env:SCOOP\buckets. Keep only few manifests prefixed with yam (to make sure non of them exists in main):
(Wrap all these steps in some Scoop-AdoptTests.ps1)
Docker-compose service which will have command: powershell.exe -File C:/SCOOP/apps/scoop/current/Scoop-AdoptTests.ps1
https://github.com/docker/compose/issues/1988#issuecomment-153377186
https://docs.docker.com/compose/compose-file/#extension-fields
It might be a good idea to replace JSON with a more readable format, but supporting more than one extension is not a good idea. It just means more documentation and unnecessary dependencies. Obviously you'd need a transition period where both JSON and the new format are supported but, keeping them both indefinitely is not a good idea.
Most helpful comment
It might be a good idea to replace JSON with a more readable format, but supporting more than one extension is not a good idea. It just means more documentation and unnecessary dependencies. Obviously you'd need a transition period where both JSON and the new format are supported but, keeping them both indefinitely is not a good idea.