diff --git a/docs/advanced/14_dependencies_in_typescript/index.mdx b/docs/advanced/14_dependencies_in_typescript/index.mdx index fdf8b1f43..2e0a50204 100644 --- a/docs/advanced/14_dependencies_in_typescript/index.mdx +++ b/docs/advanced/14_dependencies_in_typescript/index.mdx @@ -8,8 +8,8 @@ Both of these runtimes allow you to include dependencies directly in the script, There are however methods to have more control on your dependencies: +- Using [workspace dependencies](../../core_concepts/55_workspace_dependencies/index.mdx) for centralized dependency management at the workspace level. - Leveraging [standard mode](#lockfile-per-script-inferred-from-imports-standard) on [web IDE](#web-ide) or [locally](#cli). -- Overriding dependencies [providing a package.json](#lockfile-per-script-inferred-from-a-packagejson). - [Bundling](#bundle-per-script-built-by-cli) per script with CLI, more powerful and local only. 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 To learn more about how dependencies from other languages are handled, see [Dependency management & imports](../../advanced/6_imports/index.mdx). -![Dependency management & imports](../6_imports/dependency_management.png 'Dependency management & imports')
+ @@ -102,68 +106,6 @@ When a lockfile is present alongside a script at time of deployment by the CLI, />
-## Lockfile per script inferred from a package.json - -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. - - - -
- -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. - -You can write those package.json manually or through a standar `npm install `. - -Several package.json files can therefore coexist, each having authority over the scripts closest to it: - -``` -└── windmill_folder/ - ├── package.json - ├── f/foo/ - │ ├── package.json - │ ├── script1.ts - │ ├── # script1.ts will use the dependencies from windmill_folder/f/foo/package.json - │ └── /bar/ - │ ├── package.json - │ ├── script2.ts - │ └── # script2.ts will use the dependencies from windmill_folder/f/foo/bar/package.json - └── f/baz/ - ├── script3.ts - └── # script3.ts will use the dependencies from windmill_folder/package.json -``` - -The Windmill [VS Code extension](../../cli_local_dev/1_vscode-extension/index.mdx) has a toggle "Infer lockfile" / "Use current lockfile". - -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. - -![Toggle Lockfile](../../cli_local_dev/1_vscode-extension/toggle_lockfile.png 'Toggle Lockfile') - -
- - - -
- ## Bundle per script built by CLI This method can only be deployed from the [CLI](../3_cli/index.mdx), on [local development](../4_local_development/index.mdx). diff --git a/docs/advanced/15_dependencies_in_python/index.mdx b/docs/advanced/15_dependencies_in_python/index.mdx index 30fe9960a..ee4fa3584 100644 --- a/docs/advanced/15_dependencies_in_python/index.mdx +++ b/docs/advanced/15_dependencies_in_python/index.mdx @@ -6,9 +6,9 @@ In Windmill [standard mode](#lockfile-per-script-inferred-from-imports-standard) 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). There are however methods to have more control on your dependencies: +- Using [workspace dependencies](../../core_concepts/55_workspace_dependencies/index.mdx) for centralized dependency management at the workspace level. - Leveraging [standard mode](#lockfile-per-script-inferred-from-imports-standard) on [web IDE](#web-ide) or [locally](#cli). - Using [PEP-723 inline script metadata](#pep-723-inline-script-metadata) for standardized dependency specification. -- Overriding dependencies [providing a requirements.txt](#lockfile-per-script-inferred-from-a-requirementstxt). Moreover, there are other tricks, compatible with the methodologies mentioned above: - [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 To learn more about how dependencies from other languages are handled, see [Dependency management & imports](../../advanced/6_imports/index.mdx). -![Dependency management & imports](../6_imports/dependency_management.png "Dependency management & imports")
+ @@ -88,63 +92,6 @@ When a lockfile is present alongside a script at time of deployment by the CLI, description="Develop locally, push to git and deploy automatically to Windmill." href="/docs/advanced/local_development" /> -
- -## Lockfile per script inferred from a requirements.txt - -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. - - - -
- -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. - -You can write those requirements.txt manually or through a standard `pip install package_name`. - -Several requirements.txt files can therefore coexist, each having authority over the scripts closest to it: - -``` -└── windmill_folder/ - ├── requirements.txt - ├── f/foo/ - │ ├── requirements.txt - │ ├── script1.py - │ ├── # script1.py will use the dependencies from windmill_folder/f/foo/requirements.txt - │ └── /bar/ - │ ├── requirements.txt - │ ├── script2.py - │ └── # script2.py will use the dependencies from windmill_folder/f/foo/bar/requirements.txt - └── f/baz/ - ├── script3.py - └── # script3.py will use the dependencies from windmill_folder/requirements.txt -``` - -The Windmill [VS Code extension](../../cli_local_dev/1_vscode-extension/index.mdx) has a toggle "Infer lockfile" / "Use current lockfile". - -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. - -![Toggle Lockfile](../../cli_local_dev/1_vscode-extension/toggle_lockfile.png 'Toggle Lockfile') - -
- - +For centralized dependency management, see [workspace dependencies](../../core_concepts/55_workspace_dependencies/index.mdx). ### Arguments diff --git a/docs/advanced/4_local_development/generate_metadata_path.png b/docs/advanced/4_local_development/generate_metadata_path.png deleted file mode 100644 index 9623b2791..000000000 Binary files a/docs/advanced/4_local_development/generate_metadata_path.png and /dev/null differ diff --git a/docs/advanced/4_local_development/index.mdx b/docs/advanced/4_local_development/index.mdx index 85661c38d..a557c2c21 100644 --- a/docs/advanced/4_local_development/index.mdx +++ b/docs/advanced/4_local_development/index.mdx @@ -168,13 +168,7 @@ Locally, the lockfile is respected. It "wins" over the dependencies pinned via t 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. -### Package.json & requirements.txt - -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. - -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. - -![Generate Metadata Path](./generate_metadata_path.png 'Generate Metadata Path') +For centralized dependency management, see [workspace dependencies](../../core_concepts/55_workspace_dependencies/index.mdx). 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 `), 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. diff --git a/docs/advanced/6_imports/dependency_management.png b/docs/advanced/6_imports/dependency_management.png deleted file mode 100644 index f7264094d..000000000 Binary files a/docs/advanced/6_imports/dependency_management.png and /dev/null differ diff --git a/docs/advanced/6_imports/index.mdx b/docs/advanced/6_imports/index.mdx index c1e318bc6..774ced568 100644 --- a/docs/advanced/6_imports/index.mdx +++ b/docs/advanced/6_imports/index.mdx @@ -8,11 +8,11 @@ When a script is deployed through its UI, Windmill generates a lockfile to ensur On the [enterprise edition](/pricing), Windmill's caches can be configured to sync their cache with a central S3 repository to distribute the cache across multiple workers as soon as a new dependency is used for the first time. -![Dependency management & imports](./dependency_management.png "Dependency management & imports") +For centralized dependency management at the workspace level, see [workspace dependencies](../../core_concepts/55_workspace_dependencies/index.mdx). ## Lockfile per script inferred from imports (Standard) -In Windmill, you can run scripts without having to [manage a package.json](../14_dependencies_in_typescript/index.mdx#lockfile-per-script-inferred-from-a-packagejson) / [requirements.txt](../15_dependencies_in_python/index.mdx#lockfile-per-script-inferred-from-a-requirementstxt) directly. This is achieved by automatically parsing the imports and resolving the dependencies. This method works for all languages in Windmill. +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. This method works for all languages in Windmill. For more control, you can use [workspace dependencies](../../core_concepts/55_workspace_dependencies/index.mdx) for centralized dependency management. When using Bun or Deno 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. @@ -55,7 +55,7 @@ You can get those 3 files for each script by pulling your workspace with command 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. -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)](../14_dependencies_in_typescript/index.mdx#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. +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. 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.
diff --git a/docs/cli_local_dev/1_vscode-extension/index.mdx b/docs/cli_local_dev/1_vscode-extension/index.mdx index fadaef1ce..5dea5467c 100644 --- a/docs/cli_local_dev/1_vscode-extension/index.mdx +++ b/docs/cli_local_dev/1_vscode-extension/index.mdx @@ -124,7 +124,7 @@ The VS Code extension includes syntax validation for flow.yaml files, making it ### Infer lockfile or use current lockfile -With this toggle, you can choose to use the metadata lockfile ([derived from](../../advanced/3_cli/script.md#packagejson--requirementstxt) package.json or requirements.txt after [`wmill script generate-metadata`](../../advanced/3_cli/script.md#re-generating-a-script-metadata-file)) instead of inferring them directly from the script. +With this toggle, you can choose to use the metadata lockfile (derived from [workspace dependencies](../../core_concepts/55_workspace_dependencies/index.mdx) after [`wmill script generate-metadata`](../../advanced/3_cli/script.md#re-generating-a-script-metadata-file)) instead of inferring them directly from the script. ![Toggle Lockfile](./toggle_lockfile.png 'Toggle Lockfile') diff --git a/flake.lock b/flake.lock index d48d6fdb2..87897629b 100644 --- a/flake.lock +++ b/flake.lock @@ -20,11 +20,11 @@ }, "nixpkgs": { "locked": { - "lastModified": 1737062831, - "narHash": "sha256-Tbk1MZbtV2s5aG+iM99U8FqwxU/YNArMcWAv6clcsBc=", + "lastModified": 1768305791, + "narHash": "sha256-AIdl6WAn9aymeaH/NvBj0H9qM+XuAuYbGMZaP0zcXAQ=", "owner": "NixOS", "repo": "nixpkgs", - "rev": "5df43628fdf08d642be8ba5b3625a6c70731c19c", + "rev": "1412caf7bf9e660f2f962917c14b1ea1c3bc695e", "type": "github" }, "original": { @@ -35,11 +35,11 @@ }, "nixpkgs-claude": { "locked": { - "lastModified": 1755186698, - "narHash": "sha256-wNO3+Ks2jZJ4nTHMuks+cxAiVBGNuEBXsT29Bz6HASo=", + "lastModified": 1768305791, + "narHash": "sha256-AIdl6WAn9aymeaH/NvBj0H9qM+XuAuYbGMZaP0zcXAQ=", "owner": "NixOS", "repo": "nixpkgs", - "rev": "fbcf476f790d8a217c3eab4e12033dc4a0f6d23c", + "rev": "1412caf7bf9e660f2f962917c14b1ea1c3bc695e", "type": "github" }, "original": {