Profile merge concatenates things that don't make sense

[trptcolin]

If I have this in ~/.lein/profiles.clj

{:user {:repl-options {:init (set! *print-length* 20)}}}

and this in my project.clj:

{:user {:repl-options {:init (println "HI!")}}}

then the merged :repl-options end up being:

{:init (println "hi!" set! *print-length* 20)

because of meta-merge.

Ideally there would be something like a list of all the forms - is the full list of profile settings exposed anywhere that would allow the repl task to do something custom? I'm not sure what the right thing to do here would be. :(

[technomancy]

I think the right thing to do here is to make the :init value a vector containing a number of forms. But I understand the problems you get from putting the wrong thing in are going to be difficult to debug.

[hypirion]

This is an issue more general than just for :repl-options :init. Merging will also mix up other things such as pom-additions and aliases (and possibly future values). If you for instance have this within ~/.lein/profiles.clj

{:aliases {"test" ["do" "test," "midje"]}}

then having

{:aliases {"test" "midje"}}

will give you a type mismatch, and having

{:aliases {"test" ["do" "test," "midje"]}}

Will attempt to do lein do test, midje do test, midje.

Instead of solving this specific case, I think it would be nice with a solution that can handle multiple cases and minimizes work if/when another case pops up.

[technomancy]

Oy; quite right. This is tricky; it seems that ^:replace/^:displace metadata may need to be associated with keys rather than values.

We could enumerate all the non-merge keys in Leiningen itself, but plugins could introduce their own keys that need special handling too. I can't think of a simple way to do this; it may get messy.

[technomancy]

In the mean time I think :init for the repl can be addressed. However, rather than switching it for a vector I think it could probably be replaced by :injections in the :repl profile maybe.

[technomancy]

Oh... the problem with doing this in the :repl profile is that putting that profile in project.clj will shadow Leiningen's built-in :repl profile that brings in the nREPL dependency. Do we need two separate profiles for this? Perhaps a :leiningen/repl that brings in the needed deps and a :repl for user use?

[hugoduncan]

:test-selectors seems to suffer from this too.

[hugoduncan]

FWIW, in pallet we use https://github.com/pallet/pallet-map-merge to do key specific merging.

[technomancy]

I'm starting to think the best thing to do here is to default to ^:replace behaviour and only merge when explicitly asked for.

[akatov]

what is the status of this? any updates?

[hypirion]

I have some notes on this, but this won't be done before 3.0.0 to keep backwards compatibility.

[devth]

Is this a benign / ignorable error or does it actually cause problems?
Regardless of whether the types match, I'd expect the last value to win / override.

[technomancy]

Regardless of whether the types match, I'd expect the last value to win / override.

Really? You'd expect adding :dependencies in your :dev profile to wipe out the :dependencies from the top-level defproject map? This is not how most users expect it to work.

Is this a benign / ignorable error or does it actually cause problems?

When people expect it to work one way, and it works differently, there's always plenty of potential for problems.

[devth]

To clarify: I only meant when there's a type conflict. Always merge when possible. Fallback to replace when not.

[technomancy]

Always merge when possible. Fallback to replace when not.

I see--this issue is actually about the fact that "always merge when possible" is not always the correct choice--merging two lists like `(require 'xyz)` and `(println "abc")` gives you `(require 'xyz println "abc")`, which is wrong. You can see some examples of this in the comments above.

[delitescere]

Indeed, still a problem. I found it when using a combination of reloaded.repl, where I have my own :repl-options {:init (go)}, and the mvxcvi/whidbey plugin which injects another :init key.

See the specific whidbey source and leiningen issue #1997

$ lein repl
Exception in thread "main" java.lang.RuntimeException: Unable to resolve symbol: do in this context, compiling:(/private/var/folders/ss/g9z18f215rv1761klgh17nlc0000gn/T/form-init2887089488392703524.clj:1:7961)
	at clojure.lang.Compiler.analyze(Compiler.java:6688)
	at clojure.lang.Compiler.analyze(Compiler.java:6625)
...
	at clojure.main.main(main.java:37)
Caused by: java.lang.RuntimeException: Unable to resolve symbol: do in this context
...
	at clojure.lang.Compiler.analyzeSymbol(Compiler.java:7069)
	at clojure.lang.Compiler.analyze(Compiler.java:6648)
	... 28 more

$ lein with-profile +whidbey/repl,+repl cprint :repl-options
{:init (do
        (clojure.core/require (quote whidbey.repl))
        (whidbey.repl/init! nil)
        go),
 :nrepl-context {:interactive-eval {:renderer whidbey.repl/render-str}},
 :nrepl-middleware [clojure.tools.nrepl.middleware.render-values/render-values],

$ lein with-profile +repl cprint :repl-options
{:init (go), :timeout 600000}

$ lein with-profile +whidbey/repl cprint :repl-options
{:init (do (clojure.core/require (quote whidbey.repl)) (whidbey.repl/init! nil)),
 :nrepl-context {:interactive-eval {:renderer whidbey.repl/render-str}},
 :nrepl-middleware [clojure.tools.nrepl.middleware.render-values/render-values]}

Notice, though that the expanded form is not the same as the source. require has become fully-qualified, but do has not.

Also, the parens around go have been removed in the combined form, but even double-parens in project.clj does nothing useful (the problem is still the do symbol is not found):

$ lein with-profile +whidbey/repl,+repl cprint :repl-options
{:init (do
        (clojure.core/require (quote whidbey.repl))
        (whidbey.repl/init! nil)
        (go)),
 :nrepl-context {:interactive-eval {:renderer whidbey.repl/render-str}},
 :nrepl-middleware [clojure.tools.nrepl.middleware.render-values/render-values],
 :timeout 600000}

The only "workaround" is to remove my :init (go) from the :repl-options in my project.clj. Then the whidbey init takes hold properly, and I get to type (go) manually.

[technomancy]

At this point any changes to this behavior are likely to be more disruptive than the problematic behavior itself.