poly libs
When we talk about poly
libraries, we refer to 3rd-party library dependencies used by components, bases, and projects.
For poly
brick dependencies, see Dependencies.
We explored brick dependencies using the Realworld example app; we’ll continue with the same workspace to explore libraries
.
Ask poly
to report on 3rd-party libraries:
poly libs
Notice that poly
has reported on library usage across all:
projects in purple - rb
is the alias for the realworld-backend
project, and dev
is the alias for the development
project.
The dependencies for a project also include the dependencies for its bricks.
If different versions of a library are referenced, poly
will use the latest version of that library.
components in green
bases in blue
An x
means that the library is used from the src
context, and t
means that it’s only used from the test
context.
The type
column describes where the library is hosted. See Library Dependency Types.
The KB
column shows the size of each library in kilobytes.
A -
means poly
could not calculate the library size because either:
the library has not been downloaded yet
If your workspace has many bricks, you may prefer a more compact report format.
You can either set :compact-views
to #{"libs"}
in your workspace.edn or specify the :compact
argument:
poly libs :compact
You can list outdated libraries:
poly libs :outdated
Your output will differ. Here’s an example output where some libraries were out of date:
You can ask poly
to update all libraries to the latest
version in all deps.edn
for all bricks and projects via:
poly libs :update
To update specific libraries:
poly libs :update libraries:djblue/portal:com.taoensso/timbre
When using the shell, poly will, after a short pause, offer autocomplete suggestions for libraries !
|
To skip updating specific libraries, specify :keep-lib-versions
in your workspace.edn, e.g.:
{...
:bricks {"article" {:keep-lib-versions [djblue/portal]}}}
:projects {"realworld-backend" {:alias "rb"
:keep-lib-versions [clj-jwt/clj-jwt clj-time/clj-time]}
You can specify libraries in three ways in tools.deps deps.edn
files:
Type | Description |
---|---|
Maven | As a Maven dependency, e.g.:
The key is the Maven |
Local | As a local dependency, e.g.:
The key is an arbitrary identifier. A local dependency is a path to a local jar file or directory. See also: Local Dependencies. |
Git | As a Git dependency, e.g.:
The |
3rd-party library dependencies are specified in deps.edn
for each component, base, and project:
Entity | File | Scope | Location in File |
---|---|---|---|
Components |
| src |
|
test |
| ||
Bases |
| src |
|
test |
| ||
Deployable projects |
| src |
|
test |
| ||
Development project |
| src |
|
test |
|
You’ll remember that you also specify bricks and projects as :local/root
dependencies.
The poly
tool distinguishes brick dependencies from local 3rd-party library dependencies by their paths.
The poly
tool understands that when a :local/root
path starts with:
../../bases/
or ../../components/
for deployable projects
or bases/
or components/
for the development project
that it is a poly
brick dependency; otherwise, it is considered a 3rd-party library dependency.
When using the tools.deps CLI (i.e. clojure
or clj
), :local/root
dependencies only inherit :src
dependencies; :test
dependencies are ignored.
The poly
tool builds upon tools.deps but has its own test runner that it invokes for the test command.
Unlike the tools.deps CLI, the poly
also inherits dependencies from the test context for :local/root
dependencies.
If you want to run your tests directly from a project using the tools.deps CLI tool, you must duplicate test library dependencies from the bricks to the project’s deps.edn
file under :aliases > :test > :extra-deps
.
If you only run tests with the built-in test command, you don’t have to worry about this.
The library dependencies for a project are the sum of all library dependencies that are indirectly included via its bricks, together with dependencies declared by the project itself.
If different versions of the same library dependency exist, then poly
will use the latest version.
You can override the library version used for a project in its deps.edn
file.
For example:
{...
:deps {poly/article {:local/root "../../components/article"}
poly/comment {:local/root "../../components/comment"}
poly/database {:local/root "../../components/database"}
...
:override-deps {clj-time/clj-time {:mvn/version "0.15.1"}} (1)
...
}
1 | Override version of clj-time/clj-time for this project |
If you re-run the libs command:
Notice that two versions of clj-time
are listed and that the realworld-backend
project now uses version 0.15.1
.
You can override project library dependencies for projects via :override-deps
in the following places:
Entity | File | Scope | Location in File |
---|---|---|---|
Deployable projects |
| src |
|
test |
| ||
Development project |
| src |
|
test |
|
Overriding a library in the src
scope will also affect the test
scope.
If you override a library in the test
scope, it will only affect the test
scope.
Can you improve this documentation?Edit on GitHub
cljdoc is a website building & hosting documentation for Clojure/Script libraries
× close