Project

​
There are two kinds of projects in Polylith: development and deployable.
1.The development project:
This is where we work with the code, often from a REPL.
It contains all libraries, components and bases in the workspace, which is specified in ./deps.edn.
If we have any profiles then they are defined in ./deps.edn.
Any extra code, that is not part of a component or base, lives under the development directory.
2.Any deployable project:
Used to build deployable artifacts, e.g.: lambda functions, REST API's, libraries, tools, ...and more.
Lives under the projects directory where each project has its own directory.
Has a deps.edn config file that specifies which libraries, component and bases that are included.
Can optionally have a resources directory.
If the base (we normally have only one per project) and the components that belong to it, contain any tests, then they will be run when we execute the test command.
If it has any tests of its own, they will live in the test directory, e.g. projects/my-project/test.
It's discouraged to have a src directory since all production code should normally only live in components and bases.
The :project key in ./workspace.edn configures which alias each project has and whether any tests should be excluded.
Let's create a project, by executing the create project command:
1
poly create project name:command-line
Copied!
Our workspace should now look like this:
1
example
2
├── bases
3
│   └── cli
4
│       ├── deps.edn
5
│       ├── resources
6
│       │   └── cli
7
│       ├── src
8
│       │   └── se
9
│       │       └── example
10
│       │           └── cli
11
│       │               └── core.clj
12
│       └── test
13
│           └── se
14
│               └── example
15
│                   └── cli
16
│                       └── core_test.clj
17
├── components
18
│   └── user
19
│       ├── deps.edn
20
│       ├── resources
21
│       │   └── user
22
│       ├── src
23
│       │   └── se
24
│       │       └── example
25
│       │           └── user
26
│       │               ├── core.clj
27
│       │               └── interface.clj
28
│       └── test
29
│           └── se
30
│               └── example
31
│                   └── user
32
│                       └── interface_test.clj
33
├── deps.edn
34
├── development
35
│   └── src
36
│       └── dev
37
│           └── lisa.clj
38
├── logo.png
39
├── projects
40
│   └── command-line
41
│       └── deps.edn
42
├── readme.md
43
└── workspace.edn
Copied!
The tool also reminds us of this:
1
  It's recommended to add an alias to :projects in ./workspace.edn for the command-line project.
Copied!
If we don't add the alias to workspace.edn, the project heading will show up as ? when we execute the info command, so let's add it:
1
{...
2
 :projects {"development" {:alias "dev"}
3
            "command-line" {:alias "cl"}}}
Copied!
Now add user and cli to projects/command-line/deps.edn:
1
{:deps {poly/user {:local/root "../../components/user"}
2
        poly/cli  {:local/root "../../bases/cli"}
3
 ...
Copied!
All keys must be unique, and a good pattern is to prefix them with poly/ followed by the brick name, e.g. poly/user or poly/cli as in this case. The reason all paths begin with "../../" is that components and bases live two levels up compared to projects/command-line and not at the root as with the development project.
The test command will figure out what tests need to be executed. If you have reasons to run the tests for each project separately using tools.deps, then you also have to specify the test paths.
Note: All the project deps.edn config files under the projects directory specifies what bricks to include by giving a list of :local/root mappings. The poly test command uses this information to figure out what bricks and library dependencies that should be included when executing the tests, by looking into each brick's deps.edn file. tools.deps does not "inherit" test dependencies from :local/root mappings, which is the reason we have to add our dependencis as separate paths in /deps.edn to allow IDE's and other tooling to work properly.
Let's summarise where the paths/dependencies to bricks are located:
The dev project: ./deps.edn > :aliases > :dev > :extra-paths
Other projects: projects/PROJECT-DIR > deps.edn > :deps
Architecture - Previous
Base
Next - Workflow
Shell
Last modified 5mo ago
Export as PDF
Copy link