specified reply version in profiles.clj not honored

[borkdude]

I cloned the most recent reply (with fixes for issue #582) and installed it locally, using lein install (changed the version to 1.1.0-local). I specified the following in .lein/profiles.clj:

{:user {:plugins [[reply "1.1.0-local"]]}}

When I start "lein repl" I still get the old REPL (printing nil and hanging).

[technomancy]

Considering #582 is one of the biggest problems with preview4, it's important that reply be able to be bumped independently of the rest of Leiningen.

[technomancy]

In order for this to work we actually have to move reply from :dependencies in project.clj to :plugins in the :default entry of leiningen.core.project/profile. Would there be any adverse effects of not declaring a direct dependency on reply other than causing one more thing to have to be downloaded at runtime?

[borkdude]

Afaik I don't see any problems with this. Tried it out in XP (removed reply from project.clj from the leiningen checkout and included it in the default profile map as a plugin, built leiningen, moved it to self-installs and tried a repl). This worked. What about @trptcolin ?

[borkdude]

Update: after testing the above, I tried creating a default project and changed the plugin settings to:

:plugins [[reply "0.1.0-beta6"]]

When starting a repl it downloaded this dependency but it didn't seem to use that reply version, but still the one that was defined in the default profile...

To be sure of the reply version in use, I opened this issue on reply: trptcolin/reply#62

[trptcolin]

@borkdude you can always do something like ps -ax | grep java to check the versions of jars you're depending on. That said, I don't have any problem with exposing the reply version as a fn or var as well. I'm happy to take a patch, otherwise I can probably get to it sometime in the next week.

@technomancy So the difference would be that reply wouldn't be included in the leiningen standalone jar? Is it a bootclasspath thing? It seems fine to me, though it might seem a little strange to users to have to download more things even when running a non-project repl. That'll only happen once, though, so maybe not a big deal.

[borkdude]

OK, ran the following test.
In the leiningen checkout I removed the dependency on reply in project.clj. Then I added it to the default profile in leiningen.core/project.clj:

:plugins [['lein-newnew "0.3.1"] '[reply "0.1.0-beta7"]]

in the default profile map.

Made an uberjar and used that version from the lein script.

Then I made a project which uses this project.clj:

(defproject foo6 "0.1.0-SNAPSHOT"
:description "FIXME: write description"
:url "http://example.com/FIXME"
:license {:name "Eclipse Public License"
:url "http://www.eclipse.org/legal/epl-v10.html"}
:dependencies [[org.clojure/clojure "1.3.0"]]
:plugins [[reply "0.1.0-beta6"]])

When running "lein repl" from this project, it seems to use reply beta7 instead of 6 (no nil printing, no hangs).
To make sure, changed the line in leiningen.core/project.clj to just be:

leiningen.core/project.clj:

:plugins [['lein-newnew "0.3.1"]]

and built a new version of leiningen which I referred to from the lein script.

Then I tried lein repl from a non-project directory, it tells me that "repl" is not a task, which is correct since there is no reference to reply.
From the project which uses reply beta6 as a plugin, I tried lein repl and I got my nil print and hangs back, so this time it really seems to use reply beta6.

It seems that the default profile has preference over project-specific settings.

[technomancy]

The intention is that profiles win over the base project map, but the :dev profile should take precedence over the others. So it should be possible to override the default profile, but it may not be obvious how it's done on a project level. I feel like it'd be more common to change this in the :user profile, but that's definitely a drawback to the default profile approach.

Probably not as big of an issue as not being able to upgrade reply though. Certainly the download-on-demand approach is workable as it's what Maven uses, but it also could have unfortunate consequences for someone who downloads Leiningen and then goes offline without running it.

[borkdude]

Tested also with overriding :dev or :user, but no luck. :default still seems to win.

[technomancy]

I just confirmed here that adding [reply "0.1.0-SNAPSHOT"] to :plugins under ~/.lein/profiles.clj allowed my own version of reply to be used.

[borkdude]

I'm still trying to confirm on XP. In %USERPROFILE/.lein/profiles.clj I have put this: {:user {:plugins [[reply "0.1.0-beta6"]]}}
To be able to track what's going on, I removed the reply dir for from .%USERPROFILE%/.m2.
From a new project I try: "lein repl". The following error occurs: https://gist.github.com/2834097. In .m2 a directory for beta7 and beta6 are created but the dependencies are not downloaded. So far I'm not able to tell which is going to be used since the deps are not being downloaded.

[borkdude]

I tested now on Mac OSX with ~/.lein/profiles.clj having {:user {:plugins [[reply "0.1.0-beta6"]]}}
When I start a repl it downloads beta6, but I'm pretty sure the REPL I am seeing is beta7. (When changing to beta3 for example, I still see the blinking parens).