technomancy

> When doing releases using lein release if the release fails, your > project can be left in a partially released state. To fix it you > either need to...

What we really want here is a scoped memoize to it speeds things up for a single execution of a task without sticking around beyond a single call to `leiningen.core.main/resolve-and-apply`.

If we added group-id we'd have to support both until 3.0, but we could start emitting warnings for what we're currently doing when the group-id varies.

This was intentional, but the situation has changed; we can't assume deploys always happen in an attended session. The suggested fix in the original issue description is reasonable.

Thanks for this patch. I think overall it's good to surface this information, but the way it's presented in this implementation is not particularly clear. Simply saying `Suggest: ...` is...

Sorry, I haven't gotten a chance to look at this yet, but I don't think it needs to be closed. Was that intentional?

> I've never seen a project.clj with dual licensing, so that on the one > hand that might me tricky to implement in :license (if nobody did it) > or...

I think it would be good to add this to DEBUG.

I don't think this is infeasible. Any higher-order task that calls another task (not hard-coded things like uberjar calling jar) would go through leiningen.core.main/apply-task. If you added debug logging there,...

The hard-coded stuff isn't as bad as you'd think. The tricky bits of the jar creation are usually the invocation of :prep-tasks, which goes through l.c.m/apply-task.