Upstream libs break when using clojure.future.

[bamarco]

This issue onyx-platform/onyx#782 came up when an upstream lib is still using clojure 1.8 and a downstream project has already moved to 1.9.

I think we could add a (defmacro refer-future! [& syms]) macro that would define everything from clojure.future if it detects that they haven't already been defined (presumably because you are running clojure 1.9). The upstream lib calls (refer-future! any? uuid?) instead of putting that in the ns. I think this would keep warnings/errors from popping up downstream.

Alternatively we could make a file clojure.use-future that conditionally defines everything in clojure.future and you can then put clojure.future in the :use clause in the ns of the lib.

[tonsky]

Maybe I should just use some unique namespace that’s different from what Clojure Spec offers but which will work in both 1.8 and 1.9? That way conflicts would be impossible

[bamarco]

The danger with that approach is any?and the like are part of the core clojure ns in 1.9 so you get warnings if you refer any? from anybody's namespace since it's a defacto reserved word in 1.9. There might be a way to do it though if there's some clever way to trick ':refer' into not assigning when in 1.9.

[tonsky]

Ok. Try [clojure-future-spec "1.9.0-alpha17"]. I’ve changed it that under 1.9 clojure.future exports nothing so you can just always import it and won’t have any conflicts.