You’ve seen output from the info command, but we haven’t explained flags:
There are four possible flags:
Flag | Description |
---|---|
| Relates to source code |
| Relates to resources and is only shown when requested |
| Relates to tests |
| Indicates |
Fun flag facts:
Flags are booleans, poly
shows:
the flag when true
.
the -
(dash) character when false
.
Flags always appear in order: srtx
.
The r
flag isn’t included by default.
The specific meaning of a flag depends on where it appears.
We’ll cover the x
flag in more detail when we get to Testing.
For the sake of simplicity, we’ll describe the presence of sources as a single src directory and the presence of tests as a single test directory.
In reality, projects and bricks can choose to have multiple or different source and test paths.
|
From our example above:
The info
command outputs a table summarizing projects.
There is one row for each project and a status
and dev
column for flags.
status
Column FlagsFlag | Description |
---|---|
| The project has a |
| The project has a |
| The |
From our example above:
The status
flags ---
for command-line
means poly
sees:
a ./projects/command-line
directory
no ./projects/command-line/src
directory
no ./projects/command-line/test
directory
no reason to run tests for this project
The status
flags s--
for development
means poly
sees:
a ./development/src
directory
no ./development/test
directory
no reasons to run tests for this project
dev
Column FlagsFlag | Description |
---|---|
| The |
| The |
| The |
From our example above:
The dev
flags ---
for command-line
means poly
sees:
./projects/command-line/src
isn’t referenced in ./deps.edn
./projects/command-line/test
isn’t referenced in ./deps.edn
no reason to run tests for the command-line
project from the development
project
The dev
flags s---
for development
means poly
sees:
./development/src
is referenced in ./deps.edn
./development/test
isn’t referenced in ./deps.edn
no reason to run tests for the development
project
You might wonder about the
|
The development project exists to support development.
It would be unusual for it to have tests of its own.
|
From our example above:
The info
command outputs a table summarizing bricks (components and bases).
There is one row for each brick and one column for each project.
You’ll see one column for each deployable project and a dev
column for the development
project.
Our example
workspace only has the command-line
deployable project, which you’ll remember you aliased as cl.
Flag | Description |
---|---|
| The brick’s |
| The brick’s |
| The |
From our example above:
We have a single deployable command-line
project aliased as cl
.
The cl
flags st-
for the user
component means poly
sees:
the command-line
project references the user
component, and the user
component has:
a src
directory specified in its deps.edn
a test
directory specified in its deps.edn
no reason to run tests for the user
component for the command-line
project
The cl
flags st-
for the cli
base follow the same pattern.
dev
Project ColumnFrom our example above:
The dev
flags st-
for the user
component means poly
sees:
./components/user/src
is referenced by the development
project
./components/user/test
is referenced by the development
project
no reason to run tests for this brick for this project
r
flagIf you execute poly info :resources
(or the shorter poly info :r
):
Notice that poly
has included the r
(resources) flag.
Can you improve this documentation?Edit on GitHub
cljdoc is a website building & hosting documentation for Clojure/Script libraries
× close