build tool/dependency manager

[camshaft]

I wanted to start a discussion about a build tool and dependency manager. I've got a few ideas.

It would be really nice if we could do go-style remote imports to include dependencies. This would remove the configuration needed for building complex dependency trees.

This is what I'm thinking:

;; foo.jxa
(ns foo
  (require "github.com/extend/cowboy@^0.9.0#cowboy")
  (require application))

(defn+ start ()
  (application/start :cowboy)
  (application/start :foo))

;; foo-app.jxa
(ns foo-app
  (require "github.com/extend/cowboy@^0.9.0#cowboy"))

(defn+ start (type args)
  (cowboy/start_http :http 100 [{:port 8080}] []))

Just like the go imports, this would recognize github in the url.

First it would extract out the org/repo, i.e. extend/cowboy. Next it would use the github api to resolve the semver range to a tag/branch/sha. Once it is resolved, it would attempt to download the cowboy module from the github content api. Once downloaded it would store the file.

$ tree
.
├── deps
│   └── extend-cowboy-0.9.0
│       └── src
│           ├── extend-cowboy-0.9.0-cowboy.app.src
│           └── extend-cowboy-0.9.0-cowboy.erl

The module name would be rewritten so there are no name/version collisions. Any references to the module inside the file will be rewritten:

Relative requires work as well:

(ns cowboy
  (require "./cowboy_req"))

$ tree
.
├── deps
│   └── extend-cowboy-0.9.0
│       └── src
│           ├── extend-cowboy-0.9.0-cowboy.app.src
│           ├── extend-cowboy-0.9.0-cowboy.erl
│           └── extend-cowboy-0.9.0-cowboy_req.erl

From this tree of dependencies the build tool can know the exact order it needs to compile the beam files. Without the ordering being specified in the files themselves it makes it harder to compile files in the correct order.

Thoughts?

[ericbmerritt]

I like the idea of having decent dependency management. However, I am really worried about mixing the concerns of relying on a module with finding/building that module. That seems a recipe for disaster in the long run. Though I need to think more about the use cases.