extend dep. mgt. functions; add unit tests

[loomis]

Provides unit tests of the dep-as-map and map-as-dep utility functions. Verifies that the fix in the accepted PR #479 works correctly.

In addition, this PR extends these functions to treat dependency vectors that do not have a version specified, such as:

['example/project]
['example/project :scope "test"]

Such incomplete specifications are useful when handling dependency versions and options centrally. At SixSq, we use a function to pull in a central list of dependency specifications to complete any dependencies in the local build.boot file.

The change also will allow options with nil values to be retained. This may not be useful, but it eliminates a case where one function could produce a value that wasn't accepted by the other. Previously,

(map-as-dep {:project 'example/project :version "1.0.0" :option nil})
;; produced
;; ['example/project "1.0.0" :option]

which wasn't valid. It now produces:

['example/project "1.0.0" :option nil]

[micha]

Awesome PR, thanks for adding tests, too! I was looking at the :dependency-management additions to Pomegranate 0.3.1, which seem related. Boot currently uses version 0.3.0, but perhaps we upgrade that for the 2.7.0 release?

[loomis]

@micha I've not looked at the new additions to Pomegranate, so I can't judge their usefulness.

Our approach has been to keep a "dependency management" list in a separate artifact (just a normal vector of dependency specifications). This artifact is then pulled in and merged with the dependencies in the build.boot file. Our dependency declarations end up looking like:

(set-env!
  :dependencies
  #(vec (concat %
                (merge-defaults
                 ['sixsq/default-deps (get-env :version)]
                 '[[org.clojure/clojure]

                   [aleph]
                   [cheshire] ;; newer version needed for ring-json
                   [compojure]
                   [clj-stacktrace]
                   [tolitius/boot-check]]))))

where the merge-defaults function is defined here.

I think that coming up with a common approach for managing dependencies across modules in boot would be useful. If the updates to Pomegranate can help, that's great. What's the best way to come to a consensus for a solution?

[burn2delete]

@loomis @micha I agree it would be nice to have a few more utils for deps management, currently I place this in every boot project I have, would be nice if there was a proper way to do this without cluttering my boot file:

(defn read-file   [file] (read-string (slurp file)))
(defn get-deps    []     (read-file "./dependencies.edn"))
(defn get-devdeps []     (read-file "./dev_dependencies.edn"))

[loomis]

@micha @flyboarder I've submitted a PR (#507) with an implementation of managed dependencies for boot. This also allows dependencies to be read from a resource. Feedback welcome in the other PR.