Liking cljdoc? Tell your friends :D

Flags

You’ve seen output from the info command, but we haven’t explained flags:

info flags

There are four possible flags:

FlagDescription

s

Relates to source code

r

Relates to resources and is only shown when requested

t

Relates to tests

x

Indicates poly will execute tests

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.

Project Flags

From our example above:

projects

The info command outputs a table summarizing projects. There is one row for each project and a status and dev column for flags.

Projects status Column Flags

FlagDescription

s

The project has a src directory.

t

The project has a test directory.

x

The poly test command will run tests for this project

From our example above:

projects status

The status flags --- for command-line means poly sees:

  1. a ./projects/command-line directory

  2. no ./projects/command-line/src directory

  3. no ./projects/command-line/test directory

  4. no reason to run tests for this project

The status flags s-- for development means poly sees:

  1. a ./development/src directory

  2. no ./development/test directory

  3. no reasons to run tests for this project

Projects dev Column Flags

FlagDescription

s

The src directory of the project is referenced by the development project

t

The test directory of the project is referenced by the development project

x

The poly test command will run tests for the project from the development project

From our example above:

projects dev

The dev flags --- for command-line means poly sees:

  1. ./projects/command-line/src isn’t referenced in ./deps.edn

  2. ./projects/command-line/test isn’t referenced in ./deps.edn

  3. no reason to run tests for the command-line project from the development project

The dev flags s--- for development means poly sees:

  1. ./development/src is referenced in ./deps.edn

  2. ./development/test isn’t referenced in ./deps.edn

  3. no reason to run tests for the development project

You might wonder about the development row intersecting with the dev column:

  1. Isn’t that talking about the development project referencing the development project? Yes.

  2. So wouldn’t status be the same as dev for the development row? Also, yes.

The development project exists to support development. It would be unusual for it to have tests of its own.

Brick Flags

From our example above:

bricks

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.

FlagDescription

s

The brick’s src directory is referenced by the project in this column

t

The brick’s test directory is referenced by the project in this column

x

The poly test command will run tests for this brick from the project in this column

Bricks Deployable Projects Columns

From our example above:

bricks deployable projects

We have a single deployable command-line project aliased as cl.

The cl flags st- for the user component means poly sees:

  1. the command-line project references the user component, and the user component has:

    1. a src directory specified in its deps.edn

    2. a test directory specified in its deps.edn

  2. 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.

A reminder of relevant projects/command-line/deps.edn configuration:

{:deps {poly/remote {:local/root "../../components/user"}
        poly/cli    {:local/root "../../bases/cli"}

And, in turn, the relevant components/user/deps.edn and bases/cli/deps.edn configuration:

{:paths ["src" "resources"]
 :deps {}
 :aliases {:test {:extra-paths ["test"]
                  :extra-deps {}}}}

Bricks dev Project Column

From our example above:

bricks dev

The dev flags st- for the user component means poly sees:

  1. ./components/user/src is referenced by the development project

  2. ./components/user/test is referenced by the development project

  3. no reason to run tests for this brick for this project

To remind you of how src and test are referenced, the relevant portion of our ./deps.edn:

 :aliases  {:dev {:extra-deps {poly/user {:local/root "components/user"} (1)
  ...
            :test {:extra-paths ["components/user/test" (2)
1Development project referencing user component src via :local/root dep
2Development project referencing user component test via :extra-paths

The optional r flag

If you execute poly info :resources (or the shorter poly info :r):

info

Notice that poly has included the r (resources) flag.

❮TaggingTesting❯

Can you improve this documentation?Edit on GitHub

cljdoc is a website building & hosting documentation for Clojure/Script libraries

Keyboard shortcutsReport a problemcljdoc on GitHub
× close