So ... I've noticed that leiningen does a limited amount of exception pretty printing, even without io.aviso/pretty (or ultra) plugin. Is this a change to leinigen or to Clojure 1.8?

Looking at the source, I guess this dates back to Clojure 1.3. Maybe my memory is faulty, I could have sworn REPL errors were printed out as just the raw output from .printStackTrace().

@rickmoynihan: It is "correct" in the sense that uberjars are repeatable on every machine and filters out non-project-ish configuration. But yeah, it doesn't really make sense with private repositories, so I'd be happy to make repositories whitelisted. In general I feel that many issues with profiles is the fact that we'd like to use user-specific configurations that doesn't impact repeatability: :mirrors, repository credentials, plugins that only affect development, etc. It's definitely on my list on things I want to find a solution to.

@hlship: Yeah, I don't think that has changed lately.

@hypirion: Sure once an uberjar is created it's correct and repeatable... but if you can't build the uberjar in the first place Sorry not nitpicking It's clear we'd both like this behaviour to change. Incidentally I think it also affects deploy tasks not just uberjar.... What I've never really understood with leiningen is how different tasks decide what parts of profiles to use etc... It mainly just works and does the right thing - but when it doesn't it gets very confusing and you realise there's quite a bit of magic in every task. I don't really know how leiningen is built internally; but it seems that this is a wider issue - for example how does one know what keys are important to specific profiles etc? It feels like this magic is perhaps a reason why some people are moving to boot. In theory this stuff could be declared by tasks right? For example instead of just being given a whole project map that they read what they want from they could state up front what keys they use...

I don't know if the above is a fair comment - but I'm kinda curious what someone who knows a lot more about lein, thinks...

@rickmoynihan: Yeah, it's sort-of magic what profiles we merge in and which we exclude right now. I intend to make that easier to understand in the future, because it's really hard to grok at times.

@hypirion: are the profiles grouped in anyway - for example do the uberjar and deploy things share the same set of profiles?

no, deploy isn't using the same set of profiles afaik

deploy is just a small set of tasks performed in sequence

cool that's useful to know

@hypirion: I have created a PR for that issue and tested it (manually) locally - and it seems to fix the issues I have. I also ran all the existing tests and they pass. https://github.com/technomancy/leiningen/pull/2100 Out of interest when is the next release of leiningen planned?

@hypirion: not sure if you've seen this - but the latest master branch of leiningen seems to raise the following error when running lein repl

@rickmoynihan: The milestone is https://github.com/technomancy/leiningen/milestones/2.6.2 – bottom 3 issues are things that I just wait on responses on. If the others are fixed I'd push out a new version and punt the remainders. If that turns out to take longer than anticipated, then I'm probably releasing 2.6.2 in 2-3 weeks time anyway.

And I haven't seen that issue before – could you see if that happens if you remove the user-level profiles?

@hypirion: Thanks for merging my PR

@hypirion: yes the error happens with profiles.clj removed (and even outside of a lein project directory)

also in the snippet I pasted above - there was no :user profile, the profiles.clj file still contained some profiles; though I'm pretty sure I'd actually commented it out of profiles.clj

Try clearing .profiles.clj (quick way to do that is by adding {} #_ to the start of the file) I've seen that issue happen with some mean plugins, but that is a while ago.

Also, thanks for the PR