search

clj-commons / potemkin

some ideas which are almost good
572 stars 53 forks source link

Document how `import-vars` interacts with direct-linking and namespace reloading #50

Open halgari opened 7 years ago

halgari commented 7 years ago

It seems like there would be issue with direct-linking, AOT, namespace reloading etc, and import-vars can we get some documentation on these interactions? I've run in to quite a few Potemkin related bugs in the past in these areas and I'd love to see some documentation on import-vars if we're going to continue to see this library crop up in CLJ libraries.

ztellman commented 7 years ago

Hi Tim,

I'm sorry to hear that you've run into problems. In theory, there should be no mismatch with namespace reloading; if the referenced var is changed, the value for the imported var should also change [1]. As for direct-linking, it's not clear to me why this would be a problem either, since (as far as I understand) it removes any dereferencing, in which case both vars would simply represent the same value.

Can you give me some examples of the issues you've seen in the past?

[1] https://github.com/ztellman/potemkin/blob/master/src/potemkin/namespaces.clj#L3

vemv commented 3 years ago

I'm finding the specific problem that 

(binding [*compile-files* true]
  (require 'potemkin))

(or same for any other potemkin ns) will generate no .class file at all.

The implication of this, is that if you clojure.core/compile e.g. clj-http which depends on Potemkin, you will get .class files for clj-http, which internally have references to Potemkin.

So requiring an aot-compiled clj-http will fail with:

Execution error (ClassNotFoundException) at java.net.URLClassLoader/findClass (URLClassLoader.java:382).
potemkin.types.PotemkinType

It seems plausible that it's failing because AOT-compiled clj-http assumes that potekmin .class files also exist.

Does that make sense?