Allow more flexibility in keys about conform

[bitwalker]

@johnfoconnor So so sorry man, I somehow completely missed this issue. I finally (thank god) have time to dive back in to my Elixir projects...work has been out of control for 2 months straight :(. I'll try and get to this one tonight.

[johnfoconnor]

I was considering tackling this myself but i couldnt think of a reasonable way to handle delimiting the keys. I suppose you could just escape the . with a backslash but im not sure how you can specify the key data type. especially if the keypath has keys of different types. What are you thinking of?

[bitwalker]

I've got to go back and re-assess the code around that before I know for sure what I think a good solution would be. Do you have any rough ideas of what you think would be workable? Off the top of my head I'm not sure either. I think the first priority is definitely the need for non-atom key support, since I think that likely also addresses the first problem of keys containing ..

[stocks29]

I'm running into a similar issue using conform for a phoenix project. Trying to override settings from config.exs with myapp.conf ends up resulting in the following effective configuration (per mix conform.effective)

phoenix: [{Elixir,
   [MyApp: [Router: [catch_errors: true, cookies: true,
      debug_errors: false, error_controller: MyApp.ErrorController,
      host: "myapp.mydomain.com", port: 4000,
      session_key: "_myapp_key",
      session_secret: "some-session-secret",
      ssl: false, static_assets: true]]]},
  {MyApp.Router,
   [port: nil, ssl: false, static_assets: true, cookies: true,
    session_key: "_myapp_key",
    session_secret: "other-session-secret",
    catch_errors: true, debug_errors: false,
    error_controller: MyApp.ErrorController]},
  {:code_reloader, [enabled: false]}]]

Just throwing out ideas, but how about using elixir syntax to accomplish this. For example:

atom containing ".":

phoenix.:"MyApp.Router".port = 4000

arbitrary string:

myapp."some arbitrary string".port = 4000

That is kind of noisy though. Another option might be some sort of surrounding characters, like parens or backticks:

atom containing ".":

phoenix.(MyApp.Router).port = 4000

arbitrary string:

myapp.("some arbitrary string").port = 4000

[bitwalker]

Would it be enough to treat Pascal-cased keys as a contiguous atom? For example, phoenix.MyApp.Router.port = 4000 would become phoenix: [{MyApp.Router, [port: 4000]}]. I can't think of any examples where that breaks down off the top of my head, but I don't trust myself in that respect. What are your thoughts @johnfoconnor / @stocks29?

[stocks29]

I do like the simplicity. It could be seen as a little magical and not quite intuitive though, since the rule would be roughly "if there are two or more contiguous PascalCased keys, they will be merged into a single atom key." This is a special case treated differently from all other lower keys. That said, I think it handles the common case well which is the important piece so it could be seen as very intuitive.

The only downside I see is that it's no longer possible to purposely nest these atoms, although I think that is likely more of an edge case that could be worked around with a less elegant syntax if a valid use case arose. That is, if one had intended myapp.Pascal1.Pascal2.foo = 100 to evaluate to myapp: [{Pascal1: [{Pascal2: [foo: 100]}]}]. I don't have a valid use case for why someone might do this though.

[stocks29]

@bitwalker here is a pull request to address the myapp.Module.Name.key issue: #17

[bitwalker]

@stocks29 I'll merge this once I've had a chance to hear what @johnfoconnor thinks about it. As we discussed it's a bit magical, but I'm not sure what a better solution would be at this point. As long as everyone else feels ok with it, I am.

[stocks29]

@bitwalker sounds good. I obviously didn't solve the string key issue mentioned in this ticket. I can't think of an elegant way to do that unfortunately without explicitly putting quotes in or similar. Could that be accomplished with translations?

Or perhaps adding a "final_translation" concept which allows you to define a function that receives the entire merged config and make modifications before it is written out.

[yrashk]

Any updates on this? I am also running into this issue.

[bitwalker]

@yrashk Are you running into the string key issue specifically? If so, I'll probably work on adding support for quoted keys to the conf grammar.

@stocks29 What do you think about the above? So to use string-based keys, you'd do someapp."some arbitrary key" = foo?

[yrashk]

I was running into the Camel.Case keys issue

[stocks29]

@bitwalker I think that seems reasonable and straight-forward.

[bitwalker]

@stocks29 Could you test with master and let me know what issues, if any, you run in to? Quoted keys are now supported in the parser.

[smpallen99]

Here is part of my config that is causing issues:

 login_defaults: [
    {"/orange", "[email protected]"},
    {"/orange/monitor", "[email protected]"},
  ],
  phone_number_order: [
    {"Primary Phone", "1"},
    {"Secondary Phone", "2"},
  ]

I would even be happy if I could do the following in my schema:

myapp.settings.phone_number_order: [
...
  default: [
    {"Primary Phone", "1"},
    {"Secondary Phone", "2"}
  ]

[martin-langhoff]

Dupe with #47 , or just major overlap ?

[bitwalker]

Lists with arbitrary subtypes are now working properly in master, please open a new issue if there are any problems.