Please make Potemkin opt-in

[vemv]

Library Version(s)

Latest

Problem

Potemkin's import-vars isn't a great mechanism. One can find argumentation for that from very reputed sources in https://groups.google.com/g/clojure/c/Ng_GXYSrKmI/m/q0cxahB3BAAJ - it's worth a read :)

In practice, the problems I have with APIs that are potemkin-based are:

• jump-to-source will jump to a different namespace, which throws one off
  • mentioned in the mailing list thread
• potemkin-emitted vars that are :refered can confuse tools.namespace:

Execution error (IllegalStateException) at clojure.tools.namespace.repl/recover-ns (repl.clj:77).
describe already refers to: #'foo/bar in namespace: quux

...which forces one to (t.n.r/clear), which is a productivity hit.

I'd say that import-vars seemed a great idea at the time, but as the years passed it became more evident (and widely known) that it isn't.

May I suggest, please consider sunsetting the Potemkin-centric API. For the compojure.api.sweet ns, I can easily work around that (by performing the underlying requires myself), although there's the social problem that you keep fostering something broken, which can easily make newcomers lose their time to Potemkin intricacies.

For the ring.swagger.schema ns, there's the problem that it mixes import-vars with a few vars of its own (e.g. #'coerce!), so I cannot use said vars without Potemkinizing my env.

Thanks - V

[vemv]

ps - I know that ring.swagger.schema belongs to a different project (of yours), but I thought it'd be nice to create just 1 issue instead of 2, and in the repo that tends to be used more often.

[jimpil]

I couldn't agree more with the reporter :+1: