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

Component includes org.clojure/clojure as a transitive dependency #65

Closed
daveyarwood opened this issue Jul 12, 2019 · 5 comments
Closed

Comments

@daveyarwood
Copy link

To use a different version of Clojure in a project that uses component, one has to exclude org.clojure/clojure via :exclusions as a workaround to avoid bringing in Clojure 1.9.0 as a transitive dependency.

The fix for this is to specify :scope "provided" on the org.clojure/clojure dependency vector in project.clj.

I have a fix for this here -- happy to open a PR if you'd like.

@stuartsierra stuartsierra self-assigned this Jul 24, 2019
@stuartsierra
Copy link
Collaborator

Hi Dave,

Thanks for the report. I think :scope "provided" may be the more accurate way to specify the Clojure dependency, but I am curious as to what other circumstances caused this to be a problem.

Since Component version 0.3.0, the minimum required Clojure version is 1.7.0, to support conditional read. If you try to use Component 0.3.0 or later in a project on Clojure 1.6.0 or earlier, it will fail to load.

If your project has a declared or transitive dependency on any version of Clojure after 1.7.0, then most tools will silently upgrade to that later Clojure version. I can't come up with a scenario in which the declared dependency on Clojure 1.7.0 would transitively load the "wrong" version, but transitive dependencies have all sorts of edge cases, so I could have easily missed one.

Thanks,
–S

@daveyarwood
Copy link
Author

I don't recall exactly how I ran across this a couple weeks ago, but IIRC, my build tool (Boot) did load the later Clojure version, which is good, but it also emitted a warning about how it would not load Clojure 1.7.0 because it had already loaded Clojure 1.9.0 or whatever version it was that my project specified.

@stuartsierra
Copy link
Collaborator

OK, I can reproduce equivalent behavior in Leiningen, although it doesn't print a warning when overriding with a later Clojure version.

I still think :scope "provided" is probably the "correct" thing to do, but it does have a downside:

If a project depends on a version of Clojure earlier than 1.7, and it uses Component 0.3.0 or later, lein deps :tree will print a warning, and lein with :pedantic? :abort will abort.

If I change the dependency in Component to [org.clojure/clojure "1.7.0" :scope "provided"] then there is no warning, even with :pedantic?, but attempting to load the Component library will fail with a mysterious error:

Could not locate com/stuartsierra/component__init.class or com/stuartsierra/component.clj on classpath

So adding :scope "provided" removes the warning from Boot about overriding with a later version of Clojure, but potentially removes a warning about overriding with an incompatible, earlier version of Clojure.

Assuming that most Clojure users are already using 1.8 or later, I think it's an acceptable trade-off to add :scope "provided", so I will make the change.

@daveyarwood
Copy link
Author

That's an interesting find! It feels like maybe a bug in Boot (and I guess Leiningen?), or maybe pomegranate, the library that it's using to resolve dependencies.

Thanks for looking into this!

@stuartsierra
Copy link
Collaborator

This is the script I'm using to test, if anyone is curious https://gist.github.com/stuartsierra/7df465cdd4b0632b1e7a0627b7dff931

stuartsierra pushed a commit to stuartsierra/dependency that referenced this issue Mar 7, 2020
This prevents a specific Clojure version from being loaded as a
transitive dependency of this library.

See also stuartsierra/component#65
@stuartsierra stuartsierra removed their assignment Jun 2, 2022
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

1 participant