converting v2 query functions and output flags to v3

[electriquo]

hi @TomWright,

I am trying to migrate dasel v2 syntax to v3, specifically I am trying to get all services keys as follows (again, this is in dasel v2 syntax)

docker compose config | dasel -i yaml ".services.all().key()" -w -

Is there an equivalent in v3 for both the query and the -w - option?
(Related to #283 (comment))

[TomWright]

The "plain" output format isn't currently supported, but to get unquoted strings you can use -o yaml.

I was expecting this to be a simple docker compose config | dasel -i yaml 'services.keys() but it appears I never actually implemented it.

Sorry for the breakage here. I'll work on this as a feature request.

[electriquo]

While breaking changes are generally considered acceptable in a major release, it’s often preferable to avoid them when possible and maintain backward compatibility. Doing so provides several benefits:

1. Reuse existing documentation without updates
2. Keep current tests intact, avoiding rewrites and additional compatibility checks
3. Lower the barrier for contributors by reducing the need to learn a new implementation
4. Allow users to upgrade without being forced to rewrite or significantly adapt their workflows

With that in mind, I’d like to reference this comment and ask: what are your thoughts on evolving dasel in this direction? In my view, a separate project taking this approach could draw users away from dasel, especially given the time and effort invested in building its community.

[TomWright]

I completely agree with your sentiment. Unfortunately because of the somewhat straight forward approach I took with query parsing in the early days, it was very hard to maintain backward compatibility.

Dasel does actually work in a very similar way to your comment. Parsers only exist to turn file contents into an internal model. The internal functions, logic, loops, errors etc are then all executed on the representation of the model.

The query syntax now is very much inspired by kotlin/javascript.

Does this answer your question?

[electriquo]

If that's the case, I would expect that there is no need to implement any built-ins, such as .keys().
If .keys() is not a built-in, then why not to use a built-in?

Plus, why there is a need for a specific model rather than a native key/value object which the query can manipulate? (I used the term "query", but in general it could be any code accepted by the language which can operate on the native object).

Kindly elaborate on the matter.

[TomWright]

The model package exists to abstract away format-specific behaviour and provide a consistent representation across inputs. For example, things like ordered maps (which Go doesn’t support natively), metadata, comments, etc. can all be preserved and handled consistently at that layer.

I agree that using an existing language as the query layer (e.g. JavaScript) has clear benefits. It’s well known and reduces the amount of custom behaviour dasel has to maintain. The trade-off is that it introduces a much larger surface area. dasel queries are typically short and focused (filter/map/traverse), whereas adopting something like JavaScript brings in async behaviour, side effects, security concerns, and a much broader execution model.

The syntax is intentionally inspired by familiar languages (e.g. JavaScript/Kotlin) so it feels natural, while keeping the surface area small and focused on data transformation.

Similar to tools like jq, dasel isn’t just a format bridge, it provides a focused query language for working with data, just across multiple formats.

If someone wants to use JavaScript, Kotlin, PHP, etc. for more complex logic, that’s always an option (and to be honest, easily done), but it’s slightly outside dasel’s scope. The goal is to stay portable, lightweight, and solve common tasks without needing a full script.

[TomWright]

I guess to summarise:

If you want to use JavaScript (or Python, etc.), that’s already a well-supported path... Parse the input into a native object and use the language directly.

Dasel is intentionally solving a different problem: providing a lightweight, portable CLI with a small, focused query language for common data operations, without requiring a full runtime or additional code.

So rather than acting as a bridge into another language, it aims to cover the most common querying/transformation use cases directly.

[TomWright]

I've just released v3.4.0 which includes the keys func.

You may still have problems with a newline delimited list of services, however this is a simple approach that you should be able to work with.

echo 'services:
  web:
    build: .
    ports:
      - "${APP_PORT}:5000"
    environment:
      - REDIS_HOST=${REDIS_HOST}
      - REDIS_PORT=${REDIS_PORT}

  redis:
    image: redis:alpine' | dasel -i yaml 'services.keys().join(",")'
web,redis

[electriquo]

Thanks! I have to wait for this release on the official channels (brew, etc.)

[electriquo]

I wanted to have the each element of the output in a new line, but joining with a new line (\n) does not seem to work.

[TomWright]

Thanks for highlighting that. I'm releasing a new version v3.4.1 shortly which fixes string escaping issues.

This will still cause you formatting issues because it's formatted as a toml newline property but I intend to include some variation of the old "plain" output formatting to solve this.

[electriquo]

hi @TomWright,
Would you please assist in migrating the query services.nginx.build?.context? from v2 to v3?
I couldn't find any example in the docs :|

[TomWright]

I'm away for a week. Happy to help when I'm back

[electriquo]

Hi @TomWright, I hope your time-off was for a good reason and that you enjoy it.
Would appreciate your assistance :)

Thanks.

[TomWright]

You can use services.nginx.build.context ?? "some default value"

[electriquo]

Maybe I am querying incorrectly or there is a bug that might not be related to this thread.
Please let me know if you would like me to open a dedicate issue.

When a key contains a dash, the output returns the key itself. Example below:

$ echo '
services:
  foo:
    image: ghcr.io/foo/foo
  bar-baz:
    image: ghcr.io/bar/baz
' | dasel -i yaml 'services.foo'
image: ghcr.io/foo/foo

$ echo '
services:
  foo:
    image: ghcr.io/foo/foo
  bar-baz:
    image: ghcr.io/bar/baz
' | dasel -i yaml 'services."bar-baz"'
bar-baz

[TomWright]

Please wrap your "bar-baz" with the get func - it's being parsed as a string literal.

get("bar-baz")

[electriquo]

Thank you for all the assistance and the community contribution 💪