Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

multiple keys are not parsed #52

Open
robertkowalski opened this issue Feb 11, 2016 · 5 comments
Open

multiple keys are not parsed #52

robertkowalski opened this issue Feb 11, 2016 · 5 comments

Comments

@robertkowalski
Copy link

i just realised that ini struggles with input like

[remote "origin"]
    fetch = +refs/heads/*:refs/remotes/origin/*
    url = [email protected]:joyent/node.git
    fetch = +refs/pull/*/head:refs/remotes/origin/pr/*

(which is taken from a valid gitconfig)

in the ini notation multiple keys with different values are valid, but when ini parses them to JSON they get lost due to the limitations of JSON.

any ideas for a workaround or should i build a custom parser on my own instead?

@robertkowalski
Copy link
Author

first idea that came to my mind is that ini could use arrays instead of objects as a parsing result

@isaacs
Copy link
Contributor

isaacs commented Feb 11, 2016

Hrm, yeah, that is not great.

You're faced with:

  1. Current state
  2. Array-ify every value
  3. Sometimes it's an array, sometimes it's a string (ugh)
  4. All arrays all the time! Everything's an array! Tuples for the tuple gods!

@robertkowalski
Copy link
Author

:)

tuples are great! we wrote whole databases in languages which just know tuples and lists of tuples!!!!11 all we had was tuples, tuples and lists - and our bare hands!

if i would bring tuples to the offering table - would you prefer it an option or a breaking change - the current format works in many cases but is also a dead end...

i am in favour of killing the object mode...

@isaacs
Copy link
Contributor

isaacs commented Feb 13, 2016

Well, in cases like many config files, where subsequent options DO override earlier ones (as in npm's, where a key can only have a single value) it's exactly what you want. And if it isn't, then what you want is tuples all the way down, most likely.

It's only a couple hundred lines, so I'd recommend just writing a new module. The use case is different enough that supporting both will be annoying. Feel free to copy out whatever parsing code you want. It's all ISC licensed, so it's fine. If you take a lot, include a link in your license so the provenance is called out.

@robertkowalski
Copy link
Author

yeah so the whole thing i built is named tulips, and i hate it :)

https://github.com/robertkowalski/tulips/

it is not feature complete (misses the subsection feature, e.g. [a.b.c], pull requests welcome).

it was enough for my use case (parsing .git/config files)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants
@isaacs @robertkowalski and others