Fix dependency injection at jack-in time

[futuro]

Commit clojure-emacs/cider@8989f40d in cider
stopped using cider-jack-in-lein-plugins as a method for defining
the dependencies to insert, which causes the sayid dependencies to be
missed upon jack-in.

Since we're using Cider anyways, and likely using it to define our
nREPL version, we're going to leverage the more generic
cider-jack-in-dependencies variable for defining the sayid
dependency.

To avoid potential version collisions, I've opted to no longer add the
sayid plugin to the cider-jack-in-lein-plugins variable.

[bbatsov]

The problem is that there is a Lein plugin as well https://github.com/clojure-emacs/sayid/blob/master/src/sayid/plugin.clj

That's one of the messed up things about the deps injection right now - how to avoid duplicating deps for Lein projects. Probably in CIDER we should remove stuff from deps if they already appear in the plugins. For said it seems it'd be best if we add sayid to both the plugins and the deps.

[vemv]

Perhaps we can take the same exact approach as https://github.com/clojure-emacs/clj-refactor.el/blob/f368c56c83843396b160440f472a661a3b639862/clj-refactor.el#L4199-L4218, for homogeneity; that one implementation is known to work by now

[futuro]

@bbatsov would @vemv's suggestion work for sayid? (I'd totally forgotten about this issue until today when I deleted my cached package directory, also getting rid of my local copy of these changes and then wondering why sayid stopped working.)

[bbatsov]

The implementation in clj-refactor seems wrong to me, as it relies on what's the preferred build tool, instead of the actual build tool being used at jack-in time. I still think it'd be best if this was handled in a generic manner in CIDER itself by adding some extra logic for Leiningen there which strips deps that also appear as plugins. There's very little point in asking each plugin to do exactly the same thing.

[bbatsov]

For a short-term fix - here probably the dep needs to be added to both lists, instead of only to one. Kind of ugly, but it won't break anything IMO.

[futuro]

The implementation in clj-refactor seems wrong to me, as it relies on what's the preferred build tool, instead of the actual build tool being used at jack-in time. I still think it'd be best if this was handled in a generic manner in CIDER itself by adding some extra logic for Leiningen there which strips deps that also appear as plugins. There's very little point in asking each plugin to do exactly the same thing.

That's a good point about moving this solution to CIDER itself. I can take a crack at making that change, but I'm not familiar enough with lein to know whether to prefer deps or plugins. It sounds like the thing to do is remove any dep from cider-jack-in-dependencies that also shows up in cider-jack-in-lein-plugins; is that all that needs to happen?