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
Copy file name to clipboardExpand all lines: docs/advanced/14_dependencies_in_typescript/index.mdx
+8-66Lines changed: 8 additions & 66 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -8,8 +8,8 @@ Both of these runtimes allow you to include dependencies directly in the script,
8
8
9
9
There are however methods to have more control on your dependencies:
10
10
11
+
- Using [workspace dependencies](../../core_concepts/55_workspace_dependencies/index.mdx) for centralized dependency management at the workspace level.
11
12
- Leveraging [standard mode](#lockfile-per-script-inferred-from-imports-standard) on [web IDE](#web-ide) or [locally](#cli).
12
-
- Overriding dependencies [providing a package.json](#lockfile-per-script-inferred-from-a-packagejson).
13
13
-[Bundling](#bundle-per-script-built-by-cli) per script with CLI, more powerful and local only.
14
14
15
15
Moreover, there are other tricks, compatible with the methodologies mentioned above:
@@ -19,9 +19,13 @@ Moreover, there are other tricks, compatible with the methodologies mentioned ab
19
19
20
20
To learn more about how dependencies from other languages are handled, see [Dependency management & imports](../../advanced/6_imports/index.mdx).
description="Manage dependencies centrally at the workspace level for consistent environments."
27
+
href="/docs/core_concepts/workspace_dependencies"
28
+
/>
25
29
<DocCard
26
30
title="Dependency management & imports"
27
31
description="Windmill's strength lies in its ability to run scripts without having to manage a package.json directly."
@@ -36,7 +40,7 @@ To learn more about how dependencies from other languages are handled, see [Depe
36
40
37
41
## Lockfile per script inferred from imports (Standard)
38
42
39
-
In Windmill, you can run scripts without having to [manage a package.json](#lockfile-per-script-inferred-from-a-packagejson) directly. This is achieved by automatically parsing the imports and resolving the dependencies.
43
+
In Windmill, you can run scripts without having to manage dependency files directly. This is achieved by automatically parsing the imports and resolving the dependencies. For more control, you can use [workspace dependencies](../../core_concepts/55_workspace_dependencies/index.mdx).
40
44
41
45
When using Bun as the runtime for TypeScript in Windmill, dependencies are resolved directly from the script imports and their imports when using [sharing common logic](../5_sharing_common_logic/index.mdx). The TypeScript runtime Bun ensures 100% compatibility with Node.js without requiring any code modifications.
42
46
@@ -86,7 +90,7 @@ You can get those 3 files for each script by pulling your workspace with command
86
90
87
91
Editing a script is as simple as editing its content. The code can be edited freely in your IDE, and there are possibilities to even run it locally if you have the correct development environment setup for the script language.
88
92
89
-
Using [wmill CLI](../3_cli/index.mdx) command [`wmill script generate-metadata`](../3_cli/script.md#re-generating-a-script-metadata-file), lockfiles can be generated and updated as files. The CLI asks the Windmill servers to run dependency job, using either the [package.json (if present)](#lockfile-per-script-inferred-from-a-packagejson) or asking Windmill to automatically resolve it from the script's code as input, and from the output of those jobs, create the lockfiles.
93
+
Using [wmill CLI](../3_cli/index.mdx) command [`wmill script generate-metadata`](../3_cli/script.md#re-generating-a-script-metadata-file), lockfiles can be generated and updated as files. The CLI asks the Windmill servers to run dependency job, using either [workspace dependencies](../../core_concepts/55_workspace_dependencies/index.mdx) (if configured) or automatically resolving from the script's imports, and from the output of those jobs, create the lockfiles.
90
94
When a lockfile is present alongside a script at time of deployment by the CLI, no dependency job is run and the present lockfile is used instead.
91
95
92
96
<divclassName="grid grid-cols-2 gap-6 mb-4">
@@ -102,68 +106,6 @@ When a lockfile is present alongside a script at time of deployment by the CLI,
102
106
/>
103
107
</div>
104
108
105
-
## Lockfile per script inferred from a package.json
106
-
107
-
Although Windmill can [automatically resolve imports](#lockfile-per-script-inferred-from-imports-standard). It is possible to override the dependencies by providing a `package.json` file in the same directory as the script as you would do in a standard Node.js project, building and maintaining a package.json to declare dependencies.
108
-
109
-
<iframe
110
-
style={{ aspectRatio: '16/9' }}
111
-
src="https://www.youtube.com/embed/T8jMjpNvC2g"
112
-
title="Override Inferred Dependencies with Custom Dependency Files"
When doing [`wmill script generate-metadata`](../3_cli/script.md#re-generating-a-script-metadata-file), if a package.json is discovered, the closest one will be used as source-of-truth instead of being discovered from the imports in the script directly to generate the lockfile from the server.
122
-
123
-
You can write those package.json manually or through a standar `npm install <X>`.
124
-
125
-
Several package.json files can therefore coexist, each having authority over the scripts closest to it:
126
-
127
-
```
128
-
└── windmill_folder/
129
-
├── package.json
130
-
├── f/foo/
131
-
│ ├── package.json
132
-
│ ├── script1.ts
133
-
│ ├── # script1.ts will use the dependencies from windmill_folder/f/foo/package.json
134
-
│ └── /bar/
135
-
│ ├── package.json
136
-
│ ├── script2.ts
137
-
│ └── # script2.ts will use the dependencies from windmill_folder/f/foo/bar/package.json
138
-
└── f/baz/
139
-
├── script3.ts
140
-
└── # script3.ts will use the dependencies from windmill_folder/package.json
141
-
```
142
-
143
-
The Windmill [VS Code extension](../../cli_local_dev/1_vscode-extension/index.mdx) has a toggle "Infer lockfile" / "Use current lockfile".
144
-
145
-
With this toggle, you can choose to use the metadata lockfile (derived from package.json after `wmill script generate-metadata`) instead of inferring them directly from the script.
Copy file name to clipboardExpand all lines: docs/advanced/15_dependencies_in_python/index.mdx
+8-61Lines changed: 8 additions & 61 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -6,9 +6,9 @@ In Windmill [standard mode](#lockfile-per-script-inferred-from-imports-standard)
6
6
From the import lines, Windmill automatically handles the resolution and caching of the script dependencies to ensure fast and consistent execution (this is standard mode).
7
7
8
8
There are however methods to have more control on your dependencies:
9
+
- Using [workspace dependencies](../../core_concepts/55_workspace_dependencies/index.mdx) for centralized dependency management at the workspace level.
9
10
- Leveraging [standard mode](#lockfile-per-script-inferred-from-imports-standard) on [web IDE](#web-ide) or [locally](#cli).
10
11
- Using [PEP-723 inline script metadata](#pep-723-inline-script-metadata) for standardized dependency specification.
11
-
- Overriding dependencies [providing a requirements.txt](#lockfile-per-script-inferred-from-a-requirementstxt).
12
12
13
13
Moreover, there are other tricks, compatible with the methodologies mentioned above:
14
14
-[Sharing common logic with Relative Imports](#sharing-common-logic-with-relative-imports).
@@ -18,9 +18,13 @@ Moreover, there are other tricks, compatible with the methodologies mentioned ab
18
18
19
19
To learn more about how dependencies from other languages are handled, see [Dependency management & imports](../../advanced/6_imports/index.mdx).
description="Manage dependencies centrally at the workspace level for consistent environments."
26
+
href="/docs/core_concepts/workspace_dependencies"
27
+
/>
24
28
<DocCard
25
29
title="Dependency management & imports"
26
30
description="Windmill's strength lies in its ability to run scripts without having to manage a requirements.txt directly."
@@ -35,7 +39,7 @@ To learn more about how dependencies from other languages are handled, see [Depe
35
39
36
40
## Lockfile per script inferred from imports (Standard)
37
41
38
-
In Windmill, you can run scripts without having to [manage a requirements.txt](#lockfile-per-script-inferred-from-a-requirementstxt) directly. This is achieved by automatically parsing the top-level imports and resolving the dependencies. For automatic dependency installation, Windmill will only consider these top-level imports.
42
+
In Windmill, you can run scripts without having to manage a requirements.txt directly. This is achieved by automatically parsing the top-level imports and resolving the dependencies. For automatic dependency installation, Windmill will only consider these top-level imports.
39
43
40
44
In Python, the top-level imports are automatically parsed on saving of the script and a list of imports is generated. For automatic dependency installation, Windmill will only consider these top-level imports.
41
45
@@ -74,7 +78,7 @@ You can get those 3 files for each script by pulling your workspace with command
74
78
75
79
Editing a script is as simple as editing its content. The code can be edited freely in your IDE, and there are possibilities to even run it locally if you have the correct development environment setup for the script language.
76
80
77
-
Using [wmill CLI](../3_cli/index.mdx) command [`wmill script generate-metadata`](../3_cli/script.md#re-generating-a-script-metadata-file), lockfiles can be generated and updated as files. The CLI asks the Windmill servers to run dependency job, using either the [requirements.txt (if present)](#lockfile-per-script-inferred-from-a-requirementstxt) or asking Windmill to automatically resolve it from the script's code as input, and from the output of those jobs, create the lockfiles.
81
+
Using [wmill CLI](../3_cli/index.mdx) command [`wmill script generate-metadata`](../3_cli/script.md#re-generating-a-script-metadata-file), lockfiles can be generated and updated as files. The CLI asks the Windmill servers to run dependency job, asking Windmill to automatically resolve it from the script's code as input, and from the output of those jobs, create the lockfiles.
78
82
When a lockfile is present alongside a script at time of deployment by the CLI, no dependency job is run and the present lockfile is used instead.
79
83
80
84
<divclassName="grid grid-cols-2 gap-6 mb-4">
@@ -88,63 +92,6 @@ When a lockfile is present alongside a script at time of deployment by the CLI,
88
92
description="Develop locally, push to git and deploy automatically to Windmill."
89
93
href="/docs/advanced/local_development"
90
94
/>
91
-
</div>
92
-
93
-
## Lockfile per script inferred from a requirements.txt
94
-
95
-
Although Windmill can [automatically resolve imports](#lockfile-per-script-inferred-from-imports-standard). It is possible to override the dependencies by providing a `requirements.txt` file in the same directory as the script as you would do in a standard Python project, building and maintaining a requirements.txt to declare dependencies.
96
-
97
-
<iframe
98
-
style={{ aspectRatio: '16/9' }}
99
-
src="https://www.youtube.com/embed/T8jMjpNvC2g"
100
-
title="Override Inferred Dependencies with Custom Dependency Files"
When doing [`wmill script generate-metadata`](../3_cli/script.md#re-generating-a-script-metadata-file), if a requirements.txt is discovered, the closest one will be used as source-of-truth instead of being discovered from the imports in the script directly to generate the lockfile from the server.
110
-
111
-
You can write those requirements.txt manually or through a standard `pip install package_name`.
112
-
113
-
Several requirements.txt files can therefore coexist, each having authority over the scripts closest to it:
114
-
115
-
```
116
-
└── windmill_folder/
117
-
├── requirements.txt
118
-
├── f/foo/
119
-
│ ├── requirements.txt
120
-
│ ├── script1.py
121
-
│ ├── # script1.py will use the dependencies from windmill_folder/f/foo/requirements.txt
122
-
│ └── /bar/
123
-
│ ├── requirements.txt
124
-
│ ├── script2.py
125
-
│ └── # script2.py will use the dependencies from windmill_folder/f/foo/bar/requirements.txt
126
-
└── f/baz/
127
-
├── script3.py
128
-
└── # script3.py will use the dependencies from windmill_folder/requirements.txt
129
-
```
130
-
131
-
The Windmill [VS Code extension](../../cli_local_dev/1_vscode-extension/index.mdx) has a toggle "Infer lockfile" / "Use current lockfile".
132
-
133
-
With this toggle, you can choose to use the metadata lockfile (derived from requirements.txt after `wmill script generate-metadata`) instead of inferring them directly from the script.
Copy file name to clipboardExpand all lines: docs/advanced/3_cli/script.md
+1-15Lines changed: 1 addition & 15 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -85,21 +85,7 @@ Note that you can explicitly exclude (or include) specific files or folders to b
85
85
wmill flow generate-locks
86
86
```
87
87
88
-
### package.json & requirements.txt
89
-
90
-
When doing `wmill script generate-metadata`, if a `package.json` or `requirements.txt` is discovered, the closest one will be used as source-of-truth instead of being discovered from the imports in the script directly to generate the lockfile from the server.
91
-
92
-
Below is a video on how to override Windmill inferred dependencies by [providing custom package.json](../14_dependencies_in_typescript/index.mdx#lockfile-per-script-inferred-from-a-packagejson) or requirements.txt.
93
-
94
-
<iframe
95
-
style={{ aspectRatio: '16/9' }}
96
-
src="https://www.youtube.com/embed/T8jMjpNvC2g"
97
-
title="Override Inferred Dependencies with Custom Dependency Files"
Copy file name to clipboardExpand all lines: docs/advanced/4_local_development/index.mdx
+1-7Lines changed: 1 addition & 7 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -168,13 +168,7 @@ Locally, the lockfile is respected. It "wins" over the dependencies pinned via t
168
168
169
169
Locally, flows and apps are stored in a folder ending with `.flow` and `.app` respectively. They include a `flow.yaml` and `app.yaml` file respectively, and the 3 files mentioned [above](#editing-and-creating-scripts-locally) for each inline script they contain.
170
170
171
-
### Package.json & requirements.txt
172
-
173
-
If you have a `package.json` or `requirements.txt` file in the same or parent directory as your script, the `wmill script generate-metadata` command will automatically include the dependencies in the metadata file.
174
-
175
-
The lockfile for a file generated with generated-metadata will be overriden by the closest package.json from a parent or current folder if there is one.
For centralized dependency management, see [workspace dependencies](../../core_concepts/55_workspace_dependencies/index.mdx).
178
172
179
173
But what if you want to create a new script from scratch? It's also easy, just create a file with the correct extension (or run `wmill script bootstrap <path> <language>`), and simply run `generate-metadata` command to generate the metadata file. The name of the file and its location in the folder will become the script path in Windmill.
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?v=4&size=40){kind=avatar}
0 commit comments