Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
mjmeintjes opened this issue Dec 20, 2023 · 1 comment
Open

Comments

@mjmeintjes
Copy link

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
Copy link
Owner

weavejester commented Dec 20, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants