You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This feature allows one to define a "workspace" in a project file by adding
```toml
[workspace]
projects = ["packageA", "docs", "test"]
```
to it. All projects in a workspace are resolved together into a single manifest file in the "root" project (the project that is not included by any other project in a workspace). The compat of all dependencies are intersected among the projects.
Currently, every project in a workspace must be in a folder at the same level as the project that includes it into the workspace.
If the test folder is included in the workspace, running `Pkg.test` is similar to just activating the test project and including the `runtest.jl` file.
Many functions now take the `workspace` argument to decide if the function should operate on the active project or on the full workspace:
- `Pkg.precompile`
- `Pkg.status`
- `Pkg.why`
- `Pkg.instantiate`
Copy file name to clipboardExpand all lines: docs/src/toml-files.md
+18Lines changed: 18 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -128,6 +128,24 @@ constraints in detail. It is also possible to list constraints on `julia` itself
128
128
julia = "1.1"
129
129
```
130
130
131
+
### The `[workspace]` section
132
+
133
+
A project file can define a workspace by giving a set of projects that is part of that workspace.
134
+
Each project in a workspace can include their own dependencies, compatibility information, and even function as full packages.
135
+
136
+
When the package manager resolves dependencies, it considers the requirements of all the projects in the workspace. The compatible versions identified during this process are recorded in a single manifest file located next to the base project file.
137
+
138
+
A workspace is defined in the base project by giving a list of the projects in it:
This structure is particularly beneficial for developers using a monorepo approach, where a large number of unregistered packages may be involved. It's also useful for adding documentation or benchmarks to a package by including additional dependencies beyond those of the package itself.
146
+
147
+
Workspace can be nested, that ism a project that itself defines a workspace can also be part of another workspace.
148
+
In this case, the workspaces are "merged" with a single manifest being stored alongside the "root project" (the project that doesn't have another workspace including it).
0 commit comments