downgrade typesafe-config to 1.2.0 for 0.9.4?

[SethTisue]

this is blocking scala/community-build#108 because of lightbend/config#160, which is a show-stopper for us

@cunei: I would also like a 0.9.4 release in order to get the fix for #175; right now I'm having to work around it in the community build by patching the .properties files after untarring dbuild but before running it. but I'm stuck on 0.9.1 unless the typesafe config issue is also resolved. (never mind, misunderstanding about what -l does)

[SethTisue]

@eed3si9n, you're the other main user of dbuild; would downgrading Typesafe Config in the next build cause any problems for RP that you know of?

[eed3si9n]

If I'm reading lightbend/config#160 correctly, if things work on dbuild 0.9.3-M3, then downgrading to Typesafe Config 1.2.0 should continue to work because Typesafe Config 1.3.0 is more strict about the += nesting, which in 1.2.0 will silently lose information:

IMO, this is a major bug, because it silently consumes all except the last entry in the array. In my accounting application it results in an erroneous report.

Another user said:

the silent failure was simply resulting in some missing debug logs and therefore never detected

Could we fix this issue by fixing https://github.com/scala/community-builds/blob/2.11.x/common.conf?

/cc @havocp

[SethTisue]

hah. @adriaanm, if nested += in 1.2.0 doesn't work anyway, then perhaps your statement at scala/community-build#108 that "We need this construct" was too strong? it sounds we could just change our nested appends to assigns and be fine?

[adriaanm]

Yes, we can desugar it ourselves -- it's a lot of sugar though.

[SethTisue]

can you spell out what you mean by that? unless I'm missing something, we can just replace x += y with x: [y] and be done with it

[adriaanm]

i think we use it for propagating scala compiler arguments everywhere, where the addition provides a hook

[SethTisue]

you're referring to https://github.com/scala/community-builds/blob/31a6dae22366f1cf404e7cd8c9c6d87006c74283/common.conf#L143-L144, I take it.

and so yeah, I see that just overwriting the commands elsewhere isn't good enough.

I'll experiment with it and see if I can make it work.

[SethTisue]

@adriaanm if it's obvious to you what the necessary desugaring looks like, could you sketch it for me? I have almost no familiarity with Typesafe Config.

[adriaanm]

I'd have to dig in as well -- I think the += is necessary wherever a project changes the extra.commands thing property. So, you could just set it globally using a plain assignment, and then copy/paste + merge the section to whichever project appends to it.

[havocp]

I don't think downgrading will help you if you need this feature because it has never worked, in 1.2.0 it's just silent about not working.

I would probably suggest either implementing lightbend/config#30 and then we can make a new typesafe config release, or avoid references to list elements (for += to work inside a list it has to desugar to a reference to a list element).

I'm not completely sure lightbend/config#30 will work out as a fix because there may be an issue with stability of references, because ${?foo} references are allowed to disappear from a list which would affect list indices. But possibly this could be addressed in some way. (the issue is a vanishing element followed by a += element in the same list)

[SethTisue]

Closing this issue at least for now, until I'm more certain that we can't reasonably work around this. Thx all for the input.

[cunei]

@SethTisue, I will cut a new dbuild release soonish, in order to add some new stuff needed for RP. Please let me know if this issue is still current, and you need typesafe-config to be downgraded, or if this issue can be closed now. Thanks!

[SethTisue]

um, uhhhh... I don't know. and I don't really have time look into it right now (have already spent waaaay too much time on community build stuff lately), so I guess just go ahead and roll the release. I do plan to return to this later in the 2.12 cycle.

[SethTisue]

P.S. make me a committer so I can assign myself the ticket? I promise not to commit crazy stuff. unless provoked.

[SethTisue]

I don't think downgrading will help you if you need this feature because it has never worked

Havoc is right, this ticket is based on a false premise.

I was operating on the assumption that the stuff we have in common.conf that manipulates vars.base.extra must surely work or it wouldn't be there, but I realized for sure today that it doesn't work. (You can see in any of our community build run logs that any project that tries to add something extra.commands actually just overwrites it, wiping out the custom appendScalacOptions thing we always want the commands to include.)

in the context of the community build, I'll find some other way. (it's now scala/community-build#185)