Scoop: support more file extensions for manifest

Created on 30 Oct 2018  路  2Comments  路  Source: lukesampson/scoop

It is nice if we support more extension for manifest, like

  1. app.yml
  2. app.toml, etc.
enhancement

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.

All 2 comments

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.

  1. It would only required extrernal module
  2. Add wraper for parse_json like parse with arguments -Yaml -Json with default fallback

    1. Since ConvertFrom-Yaml work exactly like ConvertFrom-Json.

    2. It would require only 1 Global variable, which indicates extension

    3. Do same workflow with ConvertToPrettyYaml.



      1. Proper indentation


      2. Escape



    4. Binaries usually generate manifets, which require new function like writeManifest with extension parameter and then lines like: $json | ConvertToPrettyJson | WriteAllLines be extracted into that function

  3. Of couse fix tests, all depends lines and keep backwards compatibility.
  4. Bin for transfering json manifets to yaml manifests.

YAML Support Roadmap

  • [ ] Blockers
  • [ ] Wave 1 - Wrapper function for loading manifest (#3332)

    • [ ] parse_json -> Get-Manifest { switch (extension) { ... default: _parseJson }

    • [ ] Replace all parse_json with wrapper

  • [ ] Wave 2 (#3332)

    • [ ] Set-Manifest Path Content

    • [ ] replace all ::WriteAllLines

  • [ ] Wave 3

    • [ ] Rename $json to $manifest

  • [ ] Wave 4

    • [ ] .vscode settings

    • [ ] Download library into repository

  • [ ] Wave 5

    • [ ] Extend validator to validat yml files

  • [ ] Wave 6

    • [ ] Load module in main bin\scoop.ps1

    • [ ] Binaries



      • [ ] auto-pr





        • [ ] Inspect TODOs





      • [ ] checkver





        • [ ] ahoy







          • both architectures







        • [ ] bat







          • single architecture







        • [ ] ag







          • URL









      • [ ] autoupdate function call



  • save_installed_manifest to save only json
  • [ ] url_manifest function
  • [ ] Commands

    • [ ] install.ps1



      • [ ] Copy-Item (manifest_path $app $bucket) "$dir\manifest.json" -> (parse_manifest (manifest_path $app $bucket))


      • [ ] Remote install yaml



  • [ ] Tests

    • [ ] bin\*

      • [ ] Import Yaml module

    • [ ] Scoop-Format-Manifest.Tests.ps1 -> Scoop-Format-Manifest.json.Tests.ps1
    • [ ] Scoop-Format-Manifest.yml.Tests.ps1

      • [ ] Parse

      • [ ] Validate

  • Tests

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

  1. [ ] Make sure implementation work same for json and yaml.
  2. [ ] Commands

    1. [ ] Installing



      1. [ ] Bucket folder


      2. [ ] Remote


      3. [ ] Local full path



    2. [ ] Uninstalling



      1. [ ] Remote


      2. [ ] Bucket folder


      3. [ ] Local relative file



    3. [ ] Info

    4. [ ] Reset

    5. [ ] Update



      1. [ ] Normal


      2. [ ] Force


      3. [ ] JSON converted to yaml





        1. [ ] Normal



        2. [ ] Force






  3. [ ] Binaries

    1. [ ] checkver

    2. [ ] auto-pr

  4. [ ] Syntax

    1. [ ] Normal validated and linted manifest

    2. [ ] Control characters / proper syntax mismatch

  5. How to sanitize code to reflect new extension type

    1. Binaries

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.

Was this page helpful?
0 / 5 - 0 ratings