Would toml be supported? #1364
Comments
|
+1, I thought I had |
|
Okay cool - I'll look into a toml go library 👍🏼 |
|
Hmm the problem I'm having with the available toml libraries in go is that they are lossy. They will not only drop comments, but also the order of the keys in maps :( |
|
Adding support to this ticket, another use case I've been hoping for a toml editor is for easier editing of https://gist.github.com/mofosyne/6baab7509ccd93f74d3fa225ea57d75d In the absence of a suitable tool, I ended up using the diff and patch command, but that will likely break if there is a change to the smb.conf file in the future (but shall do for now). This feature would allow such script to be a little bit more robust. |
|
@mofosyne alternatively for this use case you can reuse it allows to do a lot of simple edition in a lot of different file format. |
|
@mikefarah It sounds as if the blocker is still the lossy go library. Is it worth someone making a non-lossy library or modifying an existing library to make it non-lossy? Did you find a library that you found particularly promising that you would prefer to use, if only it were not lossy? If we use an existing library and improve it, we could start with lossy functionality and gradually improve until toml it is on a par with yaml in terms of functionality. |
|
That said, the premier python comment-preserving toml parser is 1000 lines. Might not be that hard to convert straight to go. We could keep that option open as well. I haven't written go in a while and am rather overloaded at the moment but I could have a shot when I have time (children and startups permitting and currently on 2 hours of sleep but one can dream of a time with time). This would help me so would also save time. |
|
I've made some progress with @pelletier toml library here: #1439 - I haven't looked at it since last year. From memory I think the parsing is now working reasonably well - but it will need some work to output back and remember which bits are array tables and so forth. @pelletier and I are both keen to get it working - if someone wanted to help that'd be appreciated... |
|
I installed go and reminded myself about how it works, then cloned your branch, had a read through CONTRIBUTING.md and played with your code. I don't understand everything in the PR yet but I do note that even as it is, it is already useful. E.g. one of my original use cases was extracting some keys from a toml file to warm corresponding cache entries. The binary built in that branch already works perfectly for that use case. |
|
Do you have specific examples of things that currently don't work, that are needed for, say, initial read-only support? |
|
I'm planning on releasing a readonly version next release :) |
|
4.33.1 has support for reading TOML! |
|
Wow, I was just looking earlier this week for a toml cli that worked like yq. Thank you, this is going to be very helpful! |
|
Good progress so far :)
Next, would love to see this added as a built-in capability as well. |
This PR fixes an issue with how we mirror code in the monorepo to aztecprotocol/aztec-nr. A while back the root aztec library added a dependency on noir-protocol-circuits. In the monorepo this is achieved by use of a relative path in Nargo.toml. This works fine for contracts that pull in Aztec.nr through the monorepo (see also #3604) but it breaks projects that use [AztecProtocol/aztec-nr](https://github.com/AztecProtocol/aztec-nr) because the relative path won't exist in the mirrored repo. What this PR does is map any relative dependencies to protocol circuits to a git dependency before pushing that commit to the mirrored repo. It then undoes this change before pushing to the monorepo (we want to keep using relative paths in the monorepo). I would've preferred using `yq` since it claims it suports TOML (and is included in the default Github actions package list) but its support is limited to only basic types (so no objects like `{path="..."}`) and it can only read toml but not write it. mikefarah/yq#1364 (comment)
This PR fixes an issue with how we mirror code in the monorepo to aztecprotocol/aztec-nr. A while back the root aztec library added a dependency on noir-protocol-circuits. In the monorepo this is achieved by use of a relative path in Nargo.toml. This works fine for contracts that pull in Aztec.nr through the monorepo (see also AztecProtocol#3604) but it breaks projects that use [AztecProtocol/aztec-nr](https://github.com/AztecProtocol/aztec-nr) because the relative path won't exist in the mirrored repo. What this PR does is map any relative dependencies to protocol circuits to a git dependency before pushing that commit to the mirrored repo. It then undoes this change before pushing to the monorepo (we want to keep using relative paths in the monorepo). I would've preferred using `yq` since it claims it suports TOML (and is included in the default Github actions package list) but its support is limited to only basic types (so no objects like `{path="..."}`) and it can only read toml but not write it. mikefarah/yq#1364 (comment)
Please describe your feature request.
I wish I could use yq to work with toml files.
Describe the solution you'd like
If we have example.toml like:
And we run a command:
yq -i toml '.country' example.tomlit could output
"Australia"Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
I've tried another CLI to do this.
https://github.com/rossmacarthur/aq
But that one could only get input from stdin.
Additional context
There's another project of the same name.
https://github.com/kislyuk/yq
jqand from setup.pyyq . input.jsonyq . input.jsonyq . input.ymlyq -Y . input.ymlyq -p=xml -o=xml . input.xmlxq -x . input.xmltomlq -t . input.tomlyq -o=csv input.csvyq -o=tsv input.tsvyq -p=props -o=props input.propertiesThe text was updated successfully, but these errors were encountered: