Skip to content

Commit 157448a

Browse files
committed
Refine docs.
1 parent c04757a commit 157448a

4 files changed

Lines changed: 62 additions & 4 deletions

File tree

docs/source/how_to_guides/bp_structure_of_a_research_project.md

Lines changed: 4 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -23,6 +23,10 @@ As an example, look at two repositories from a COVID-19 forecasting project.
2323
- [sid](https://github.com/covid-19-impact-lab/sid) contains the code for the
2424
epidemiological model which is applied in the research project.
2525

26+
```{seealso}
27+
Consider using [workspaces](using_workspaces.md) which instead of separate repositories.
28+
```
29+
2630
Separating the model code from the research project provided several benefits.
2731

2832
- The model code is isolated and has its own test suite. Assessing and ensuring the code

docs/source/how_to_guides/index.md

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -23,6 +23,7 @@ provisional_nodes_and_task_generators
2323
writing_custom_nodes
2424
extending_pytask
2525
the_data_catalog
26+
using_workspaces
2627
```
2728

2829
## Best Practice Guides
Lines changed: 51 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,51 @@
1+
# Using workspaces
2+
3+
There are situations where you want to structure your project as a multi-package
4+
workspace. Reasons are
5+
6+
- You are developing a scientific package alongside the project that you want to publish
7+
later.
8+
- The code for dealing with the dataset should be reused in other projects.
9+
- You want to strictly separate the pytask tasks from the remaining code to be able to
10+
switch to another build system.
11+
12+
In those instances, a workspace might be the right choice.
13+
14+
```text
15+
project
16+
├── packages
17+
│ ├── data
18+
│ │ ├── pyproject.toml
19+
│ │ └── src
20+
│ │ └── data
21+
│ │ ├── __init__.py
22+
│ │ └── ...
23+
│ ├── analysis
24+
│ │ ├── pyproject.toml
25+
│ │ └── src
26+
│ │ └── analysis
27+
│ │ ├── __init__.py
28+
│ │ └── ...
29+
│ └── tasks
30+
│ ├── pyproject.toml
31+
│ └── src
32+
│ └── tasks
33+
│ ├── __init__.py
34+
│ └── ...
35+
36+
├── pyproject.toml
37+
├── README.md
38+
├── ...
39+
```
40+
41+
## Using workspaces with uv
42+
43+
uv provides excellent support for workspaces which you can read more about in the
44+
[uv documentation](https://docs.astral.sh/uv/concepts/projects/workspaces).
45+
46+
## Using workspaces with pixi
47+
48+
pixi is still working on a native workspace experience, but there are workarounds.
49+
50+
- https://github.com/prefix-dev/pixi/discussions/387
51+
- https://github.com/Andre-Medina/python-pixi-mono-template

docs/source/tutorials/set_up_a_project.md

Lines changed: 6 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -6,6 +6,12 @@ tutorial explains the minimal setup.
66
If you want to use pytask with a collection of scripts, you can skip this lesson and
77
move to the next section of the tutorials.
88

9+
```{seealso}
10+
In case you are thinking about developing multiple packages in the project that should be separated (one for dealing with the data, one for the analysis and a package for the pytask tasks), consider using a [workspace](../how_to_guides/using_workspaces.md).
11+
```
12+
13+
## The directory structure
14+
915
The following directory tree gives an overview of the project's different parts.
1016

1117
```text
@@ -93,10 +99,6 @@ paths = ["src/my_project"]
9399
94100
uv automatically handles build system configuration and package discovery.
95101
96-
```{seealso}
97-
Another benefit of using uv is that it makes it easy handling repositories with multiple packages allowing you to separate the package with tasks from your potential scientific package. Read more about [workspaces in the uv documentation](https://docs.astral.sh/uv/concepts/projects/workspaces/).
98-
```
99-
100102
````
101103
102104
````{tab-item} pixi

0 commit comments

Comments
 (0)