Open trptcolin opened 9 years ago
I'm pretty sure this is a dupe of #1378?
memoize
is fundamentally at odds with embedding lein, which Cursive, CCW and Nightcode all do, unless what is being memoised is truly referentially transparent. From what I can see this is pretty much never the case.Ah, right. So #1378 is a subset of these problems – that memoize calls we use aren't referentially transparent, and makes things a mess for tools trying to integrate with lein.
It would be really good to get this fixed before 3.0.0. Even if this is relatively imminent, it will be a long time before everyone migrates over and if it's not 100% compatible then I won't be able to bundle it for a long time to come. I'm going to take a look at the existing cases and decide whether just removing them is a better option than further complicating things by adding another dependency with a tricky use case.
@cursiveclojure, I put the 3.0 tag on it as it tackled a bigger set of issues compared to #1378, which also had the 3.0 milestone. I just verified with Phil that it's not problematic to fix these issues before 3.0.0.
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
.
@cursiveclojure is running into some issues where the use of
memoize
in leiningen-core means that, for instance, dependencies don't get re-computed if you change profiles. Worst-case, it would be nice if we could use a memoizer that allows clearing (https://github.com/clojure/core.memoize ?), so that clients of leiningen-core don't run into these kinds of weird caching issues.If I'm interpreting the docs right, it looks like several of the
memoize
usages are only to prevent duplicatewarn
calls, and also a few for real performance reasons. Maybe some resettable thing could fix it?