jc does not retain letter case of keys when converting from .ini to .json

[zenoweed]

jc does not retain letter case of keys when converting from .ini to .json

[kellyjonbrazil]

Could you try with the -r option? I thought I added the capability to retain the case of key names but that may have been another parser.

[zenoweed]

Apparently not. Here is the output:

brian@aspire:~$ cat file.ini | jc --ini -p -r
{
  "something_key": "djhasjdhasdk",
  "something_else_key": "WBCKDJCBDS",
  "something_else_entirely_key": "4BH4J4dncdd"
}

[kellyjonbrazil]

Thanks, I’ll take a closer look.

[kellyjonbrazil]

Ah I see this is why it seemed familiar. I was able to preserve case in the kv parser, which also uses the configparser library like the INI parser does.

jc/jc/parsers/kv.py

Line 126 in 4cd721b

# don't convert keys to lower-case:

Don't want to change the default behavior, but I could either make it so -r also does not change case or just create a new INI parser that does this.

[zenoweed]

Hi Kelly, so sorry for the delayed response. Well retaining cases with -r sounds good . But shouldn't retaining letter cases be the default behavior? As far as I know programming variables are always case sensitive. Does it help anyone when the key letter cases are converted to lowercase?

As in my case they are environment variables and will always have to be capitalized, for now as a go around I'm using jc and piping it to jq which capitalizes the keys for me:

cat repository/.${ENVIRONMENT}.ini | jc --ini -r -p | jq 'to_entries | map({(.key | ascii_upcase): .value}) | add' > .${ENVIRONMENT}.json

[kellyjonbrazil]

I absolutely agree with you that it should be the default, but this would be a breaking change for anyone currently using the INI parser in their scripts. I could deprecate --ini and create --ini2 or something.

Unfortunately, I didn't realize the configparser library was doing that and there was a way to stop it in when I first developed the INI parser, so now it's been out there in production like this for a while.

I do have a way to deprecate parsers, so maybe I'll go that route. I'll have to think about a good way to do it here.

[kellyjonbrazil]

What version of jc are you using? (jc -v)

This should already be working as expected since version 1.22.0.

[zenoweed]

Hi Kelly,

So looks like mine is an older version. I had installed it using apt. I'm currently on ubuntu 22.04.3 LTS, Gnome 42.9 if that helps.

brian@aspire:~$ jc -v
jc version 1.17.3
https://github.com/kellyjonbrazil/jc
© 2019-2021 Kelly Brazil

[kellyjonbrazil]

Ah yes, that makes sense. You can copy this ini.py file to you parser plugin directory to get the new behavior until you can upgrade jc:

https://github.com/kellyjonbrazil/jc/blob/master/jc/parsers/ini.py

• Linux/unix: $HOME/.local/share/jc/jcparsers
• macOS: $HOME/Library/Application Support/jc/jcparsers
• Windows: $LOCALAPPDATA\jc\jc\jcparsers

[zenoweed]

Thank you for this. But I was curious as to why I did not get the latest jc using apt. Neither did the ubuntu ec2 my company's Jenkins runs on.

[kellyjonbrazil]

It looks like the package maintainers don't automatically upgrade the jc package on Ubuntu unless it is requested. Here is the latest information: https://repology.org/project/jc/versions

Instead of installing via OS package, you can also install via PIP or by downloading and running the precompiled binary.

[zenoweed]

Ok. Thank you for this. The pip option sounds so much better.