search

weavejester / medley

A lightweight library of useful Clojure functions
Eclipse Public License 1.0
870 stars 67 forks source link

Incompatibility between medley/medley and dev.weavejester/medley #85

Open mjmeintjes opened 11 months ago

mjmeintjes commented 11 months ago

I recently started getting an error after deploying that m/partition-between could not be found.

That was strange, because I only had dev.weavejester/medley {:mvn/version "1.7.0"} in my deps.edn.

This took quite a bit of digging, but what I finally discovered is that several of my other dependencies still had dependencies on various old versions of medley/medley

Because Clojure/Java doesn't know that they are the same package, both were included in the classpath, which caused the old medley.core to take precedence in some cases, which meant that the m/partition-between function was not available.

The fix for me was to run clj -Stree to get a tree of all my dependencies, and then add :exclusions [medley/medley] to all the other dependencies that use the old medley versions. This a bit error-prone, as all new dependencies have to be checked, as well as any dependencies of those dependencies.

I'd be interested in any better suggestions for dealing with this issue.

weavejester commented 11 months ago

Unfortunately this is a known problem with no known solutions.

When Clojars deprecated the use of the medley/medley naming scheme for artifacts, I thought that I'd update Medley to the new scheme, forgetting that this would leave a gap in the dependency chain that would cause the exact problems you have run into.

I wasn't the only developer to make this mistake, but after some discussions with the Clojars team the resulting conclusion is currently that there is no solution for this. Those that only recently altered their artifacts could change back, but Medley unfortunately had gone through a few releases before this problem was caught.

Changing back to medley/medley at this point would break any dependencies relying on dev.weavejester/medley - the same problem just in the opposite direction - so the least bad option seems to be sticking with what we have and eventually the number of libraries that use medley/medley will dwindle as they're updated.

I could probably add a note in the README to mention this problem, but that's the best idea I have.