Dependency cycle for clj-pdf - Curive 1.8.0 IntelliJ 2018.2 and 2018.3

[alin-posorovaschi-otm]

I have a Leiningen project that uses clj-pdf version [clj-pdf "2.2.33"]. Everything worked fine with Cursive version (1.7.x) but when I upgraded to 1.8.x the same project stopped compiling in Cursive with a Dependency cycle error (i.e. cannot load any file that depends on clj-pdf into the REPL). I experienced this issue with IntelliJ Community Edition versions 2018.2.x and 2018.3.x. I had to downgrade Cursive to continue my work.
I'm using the paid version of Cursive.

[awkay]

I've got the same problem, and I figured out how it was happening for me, so perhaps it will help solve this other issue as well:

I was working on a library, that had a dependency on another library, which itself used the library I was working on. This caused the source of the library and the jar of the library to both be on the classpath. The namespaces that had the problem did the :require-macros this-ns trick for cljc, and I'm guessing cursive found both versions of the file and went in a loop.

I fixed it by running:

clj -Stree

with the proper aliases, and adding exclusions to keep the extra version from coming in.

[ism-ssw]

+1 for allowing this issue to be reported (as it was previously) but still allow the code to be loaded into the REPL. Whilst I agree that it would be nice to prevent these types of things happening ( usually only found when recompiling or restarting the repl) the previous warning only at least allowed me to carry on regardless. The new version prevents any REPL reload.

clj-pdf seem to use some hooky method to get around the circular dependency to allow it to compile but it seems that Cursive is finding this.

section.clj has two requires statements - one at the end of the file preceded by a rather nice comment stating
;; that require is here to overcome circular import

Not sure how legitimate this is but that it can work suggests others may do the same

[ism-ssw]

@alin-posorovaschi-otm how did you downgrade? Thx

[ism-ssw]

FWIW - with clj-pdf, as it is only core/pdf I was using I dynamically linked like so

(require (symbol "clj-pdf.core"))
(def pdfc-pdf
  (ns-resolve (symbol "clj-pdf.core") (symbol "pdf")))

I had to use (symbol "...") to prevent cursive from detecting anything

Then

(pdfc-pdf [{}
                                        [:list {:roman true}
                                         [:chunk {:style :bold} "a bold item"]
                                         "another item"
                                         "yet another item"]
                                        [:paragraph "yet more text"]] "fred.pdf")

works fine

[alin-posorovaschi-otm]

@ism-ssw
Thank you for the workaround! But I'm not sure adding that in production code, with the sole purpose of working around a problem with Cursive is a viable option for me.
I agree with you that the previous behavior: a waring when loading the file in the REPL is the better approach.
Regarding the downgrade: I installed the previous IntelliJ version (2018.2.x) and installed Cursive from file as it is mentioned in the Downgrading Cursive section from the User Guide, i.e. downloaded it from previous versions.

[cursive-ide]

Thanks for the comments everyone. I think a better solution is actually for Cursive to understand when a require will cause the dependency cycle error in Clojure, and only prevent loading when that would happen anyway, and give a warning otherwise. This has actually come up in the past with one of ztellman's projects, but I can't find the issue right now.

[cursive-ide]

Here's the relevant discussion in the Clojure mailing list: https://groups.google.com/d/topic/clojure/wrVFuCjf0_Y/discussion

[ism-ssw]

Thanks for the update. To be honest, I am quite surprised that the workaround in clj-pdf actually did work.
https://github.com/clj-pdf/clj-pdf/blob/master/src/clj/clj_pdf/section.clj
you will see in this that the last line contains a require that includes other files which are dependent on section.clj. If this is permissible I am not sure if this helps you to refine your dependencies logic?

[alin-posorovaschi-otm]

@cursive-ide
Thanks for chipping in and for building Cursive!

Are you referring to the following issue:
#1298
?

As for what happens in clj-pdf, as @ism-ssw already mentioned, clj-pdf.section has the following require at the end of the file:

;; that require is here to overcome circular import
(require '[clj-pdf.section core cell chart svg table])

And clj-pdf.section is required in clj-pdf.core:

(ns clj-pdf.core
  (:require
  ;; ...
   [clj-pdf.section :refer [make-section *cache*]])
;; More imports and requires
)

So, without looking to manifold's code, it seems to me this is related to it, in that the cyclic dependency does not appear in the ns require section, but is being flagged by the Cursive check (which, by the way, does a great job otherwise).

[hlship]

What version of Cursive doesn't have this issue? I need to downgrade, pronto!

[alin-posorovaschi-otm]

@hlship
I'm using 1.7.0-2018.2.

[hlship]

Do we know if IJ 2019.1.2 fixes this problem?