Problem:
Often, project developers would like to package as much as possible into the smallest set of project names. This is to minimize creation of new project files and separate repositories (eg. on github), which is work/stress for the project creator. The users of the project, however, prefer everything to be split up as much as possible to minimize the expansion of dependencies that will be included in their project.
For example, with Raynes/conch https://github.com/Raynes/conch , let say I only want to use the low level library, and not use the higher level abstraction, then I would not need [org.flatland/useful "0.10.6"](which pulls in additional dependencies).
While I could exclude this as a dependency there are some issues:
It's not made explicit that I don't plan to use the high level namespace.
It removes the potential of me wanting to use it in the future (at runtime)
The cause of this is because dependencies are specified for all namespaces. If it can be specified per namespace, then we can guarantee that:
Changes in API of the dependency can occur in lock step, the user only needs to update the version of the project
The project developer can write as many utility namespaces that may be relevant and not be concerned with dependency bloat
The project user won't be afraid to depend on large framework/like libraries since they can specify just the subset they require
Lazy usage comes for free, we can choose to acquire the utility namespaces only as they are required
Other common use cases:
clojurescript/clojure libraries that share much common code, we don't want to pull in clojurescript if we only want the clojure side.
Solution:
Currently, I at least feel there should be some discussion about this.
The backwards compatible approach would be to have a project-wide dependencies via :dependencies, and then another one where you can specify per namespace like
:ns-dependencies {'pixie.core [[foo/bar "1"] [foo/baz "1"]], 'pixie.string [[poo/bez "2"]]}
Problem: Often, project developers would like to package as much as possible into the smallest set of project names. This is to minimize creation of new project files and separate repositories (eg. on github), which is work/stress for the project creator. The users of the project, however, prefer everything to be split up as much as possible to minimize the expansion of dependencies that will be included in their project.
For example, with Raynes/conch https://github.com/Raynes/conch , let say I only want to use the low level library, and not use the higher level abstraction, then I would not need [org.flatland/useful "0.10.6"](which pulls in additional dependencies).
While I could exclude this as a dependency there are some issues:
The cause of this is because dependencies are specified for all namespaces. If it can be specified per namespace, then we can guarantee that:
Other common use cases: clojurescript/clojure libraries that share much common code, we don't want to pull in clojurescript if we only want the clojure side.
Solution: Currently, I at least feel there should be some discussion about this. The backwards compatible approach would be to have a project-wide dependencies via :dependencies, and then another one where you can specify per namespace like :ns-dependencies {'pixie.core [[foo/bar "1"] [foo/baz "1"]], 'pixie.string [[poo/bez "2"]]}