Skip to content
This repository has been archived by the owner on Jan 6, 2023. It is now read-only.

Clojure.future from clojure-future-spec interferes with using onyx with clojure 1.9. #782

Closed
bamarco opened this issue May 17, 2017 · 8 comments

Comments

@bamarco
Copy link
Contributor

bamarco commented May 17, 2017

@MichaelDrogalis I figured out a fix. spec.alpha doesn't really seem to help just made me have to update all the namespaces for no apparent reason. I did figure out a fix though. There are two possibilities: You can use a more complicated require like this

#?(:clj
(when (and (<= (:major *clojure-version*) 1)
           (<= (:minor *clojure-version*) 8)
           (find-ns 'clojure.future))
  (require 'clojure.future)
  (refer 'clojure.future :only '[any? boolean? uuid? pos-int?])))

I've tested it in both clojure 1.8 and 1.9 and it works.

The other option would be to (:use [clojure.future]) and patch clojure-future-spec so it only overwrites those functions if they don't already exist (either by checking the version or for their existence).

@bamarco bamarco changed the title Clojure.future from clojure.future.spec interferes with using onyx with clojure 1.9. Clojure.future from clojure-future-spec interferes with using onyx with clojure 1.9. May 17, 2017
@bamarco
Copy link
Contributor Author

bamarco commented May 17, 2017

The only issue at point are warnings from prismatic/schema and from clj-fuzzy. But they allow the code to run fine.

@MichaelDrogalis
Copy link
Contributor

This one's tough because we're intercepting the presence of a dependency. (clojure.future). I think I'd prefer to conditionally define those functions ourselves (any?, boolean?, etc) based on their own existence rather than the version of Clojure & a loaded namespace.

@bamarco
Copy link
Contributor Author

bamarco commented May 18, 2017

Yeah. I agree. I think this could be done in clojure-future-spec itself. I'll see if they're open to it over there.

Oh wait. There's an easier way. Just do conditional defs instead of putting the :refer clause in. That should work fine. I see what you mean.

@bamarco
Copy link
Contributor Author

bamarco commented May 18, 2017

Yup, this works:

#?(:clj
(when (not (resolve 'any?))
  (def any? clojure.future/any?)))

#?(:clj
(when (not (resolve 'boolean?))
  (def boolean? clojure.future/boolean?)))

#?(:clj
(when (not (resolve 'uuid?))
  (def uuid? clojure.future/uuid?)))

#?(:clj
(when (not (resolve 'pos-int?))
  (def pos-int? clojure.future/pos-int?)))

@MichaelDrogalis
Copy link
Contributor

Cool, yeah I'd like to see if clojure.future would be open to adding a patch similar to this first. If not, it's worth it to put it in Onyx. I don't think this problem is going away until Clojure officially moves to 1.9. We'll immediately make the upgrade in Onyx when that does happen.

@tonsky
Copy link

tonsky commented May 29, 2017

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.

@MichaelDrogalis
Copy link
Contributor

@tonsky Thanks! I'll give this a shot -- this should help a lot of the 1.9 transition in other projects too. :)

@MichaelDrogalis
Copy link
Contributor

Fixed, thanks @tonsky! This will go out in the next release. It's out on 0.10.0-20170529.194620-127 now.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants