Aidan Dunphy
09/17/2025, 9:33 PMMarvin
09/17/2025, 9:33 PMMarvin
09/17/2025, 9:48 PMuvx
to pull code from GitHub. Pulling source for flow.from_source(...)
is done with git
. If you’re seeing uvx: not found
, it’s usually coming from your runtime environment (image/machine) or a pre/post step in your project that invokes uvx
.
- Did anything change today in your execution environment?
- If you’re using a Serverless work pool, please let me know — we’ve seen a couple of reports today of “uvx not found” in serverless runs due to an environment image change.
- If you’re using your own Docker/Kubernetes/Process worker, did the base image or startup script change?
To help me help you faster, please share:
- Flow run ID (or a link to a failing run)
- Work pool type (Serverless, Docker, Kubernetes, Process)
- Your deployment’s from_source
config (URL + entrypoint), and whether you have any pre/post-run commands
- The exact error snippet from the logs
Workarounds you can apply immediately:
- If your repo or startup commands rely on uvx
, make sure the runtime has it installed. For Docker/K8s workers, add to your image:
RUN curl -LsSf <https://astral.sh/uv/install.sh> | sh
ENV PATH="/root/.local/bin:${PATH}"
For Process workers, install uv on the machine and ensure uvx
is on PATH.
- If you don’t intend to use uvx
, search your project scripts or deployment steps for any accidental uvx
calls and replace with pip
or remove them.
- If you’re on Serverless and this started today, pinning to a known-good Docker image in a non-serverless pool (temporarily) or avoiding uvx
in your steps can unblock you while we confirm the environment change on our side.
References:
- Prefect 3 deployments from source: Create deployments from source
- uv installation docs: uv installation
- Latest Prefect releases (in case you pinned a new image today): Prefect releases
Once I have the log snippet and your pool type, I can give you a precise fix (and if this is a serverless image regression, I’ll escalate accordingly).Aidan Dunphy
09/17/2025, 9:53 PMAidan Dunphy
09/17/2025, 9:55 PMMarvin
09/18/2025, 8:43 AMMarvin
09/18/2025, 8:43 AMAidan Dunphy
09/18/2025, 8:54 AMMarvin
09/18/2025, 8:54 AMMarvin
09/18/2025, 8:59 AMprefect version
python -V
- Your entrypoint (e.g., ./flows/my_flow.py:my_flow
) and any relevant bits of your prefect.yaml
(name/work_pool/entrypoint/build/push/pull steps)
Quick checks that often pinpoint deploy/import issues in Prefect 3.x:
1) Does your flow import cleanly in the same venv?
python -c "from pathlib import Path; import importlib.util, sys; p=Path('./path/to/flow.py'); spec=importlib.util.spec_from_file_location('flow_mod', p); m=importlib.util.module_from_spec(spec); spec.loader.exec_module(m); print(getattr(m,'my_flow',None))"
If this fails, the deploy will too. Recent code changes (even outside uvx) commonly trigger import errors during prefect deploy
because Prefect imports the entrypoint to read parameters/metadata.
2) Confirm you’re on the intended Cloud profile/workspace in the same environment:
prefect cloud workspace ls
prefect cloud workspace set # if needed
3) Compare versions between uvx and your venv (sometimes they drift):
- In venv: prefect version
- With uvx: uvx prefect version
Common culprits after code changes
- Relative imports or package layout changes causing ModuleNotFoundError
when run from the project root used by deploy
- Top-level side effects (env lookups, network calls) running at import time and failing during prefect deploy
- Dependency not installed in the venv (deploy imports your module right away)
- Entry point path/name mismatch (e.g., file moved or flow function renamed)
- prefect.yaml
out of sync with your code (wrong entrypoint
, wrong build/push steps)
If helpful, I can review your prefect.yaml
and entrypoint for gotchas. Also, if you tell me where the error occurs in the deploy output (e.g., while “Importing flow…”, “Uploading project…”, “Building image…”) that narrows things quickly.
Docs for reference (Prefect 3.x):
- Deployments and prefect.yaml: prefect.yaml guide
- CLI reference for deploy: prefect deploy CLI
Once I see the exact error text and your entrypoint/prefect.yaml, I can pinpoint the fix.Aidan Dunphy
09/18/2025, 9:20 AMMarvin
09/18/2025, 9:20 AMMarvin
09/18/2025, 9:20 AMMarvin
09/18/2025, 9:23 AMMarvin
09/18/2025, 9:25 AMRunning run_shell_script step...
[Errno 2] No such file or directory: 'uvx'That means your deployment’s pull/build steps (the ones that run on the worker just before importing your flow) include a run_shell_script that invokes
uvx
. On Prefect Cloud workers, uvx
is not present by default, so the step fails before your flow imports. This is unrelated to your local venv; Cloud is executing in a clean runtime where uvx
isn’t installed.
Why it still happens after you “removed uvx”
- Even if your local deploy command doesn’t mention uvx
, your deployment spec may still contain a step that calls it.
- The --with-requirements
shortcut you’re using may be implemented as a shell step that runs uvx ...
in your prefect-cloud
wrapper.
- Result: Cloud side still tries to execute uvx
and fails.
Confirm what steps your deployment has
- Run this to see the saved steps Prefect will execute:
prefect deployment inspect "<flow-name>/<deployment-name>"
Look for “steps” or a “pull” section and any occurrence of run_shell_script
or a script starting with uvx ...
.
Two ways to fix it
Option A (recommended): Use pip in your pull steps instead of uvx
- Define your pull steps explicitly in prefect.yaml
so the worker installs requirements with pip:
deployments:
- name: run_proactive
entrypoint: orchestrator/run.py:run_proactive
work_pool:
name: <your-pool>
steps:
pull:
- prefect.deployments.steps.pull.set_working_directory:
directory: .
- prefect.deployments.steps.utility.pip_install_requirements:
requirements_file: requirements.txt
- Redeploy:
prefect deploy orchestrator/run.py:run_proactive -n run_proactive
- Then trigger a run. This uses pip on the worker and avoids any call to uvx
.
Option B: Keep using uvx by baking it into your worker image
- If you control the worker runtime (e.g., Docker work pool), install uv so uvx
is on PATH. For example in a Dockerfile:
# ... your base image
RUN curl -LsSf <https://astral.sh/uv/install.sh> | sh \
&& ln -s /root/.local/bin/uvx /usr/local/bin/uvx
- Rebuild/push the image, update the work pool’s base image, and redeploy. Now the existing run_shell_script that calls uvx
will work.
If you want to keep using the CLI shortcut
- Remove --with-requirements
from your prefect-cloud deploy ...
command and let the explicit pip_install_requirements
step in prefect.yaml
handle dependency install. That ensures pip is used on Cloud.
- If prefect-cloud deploy
has a way to force pip instead of uvx for the requirements step, use that flag. If not, the explicit step above is the safest.
Notes on version drift
- The Prefect version and Pydantic drift you saw between local venv and uvx
installs isn’t the immediate cause of this error. The crash is specifically “command not found: uvx”.
- It’s still a good idea to keep Prefect versions aligned between local and Cloud to avoid other surprises.
Docs
- Prefect 3.x deployments and prefect.yaml: prefect.yaml guide
- CLI reference (deploy): prefect deploy CLI
If you share the output of:
prefect deployment inspect "<flow-name>/<deployment-name>"
I can point to the exact step that’s calling uvx
and give you a drop-in replacement using pip_install_requirements
. Also, which work pool/infrastructure are you using (Managed, Process, Docker, Kubernetes)? That determines whether Option A or B is better.Aidan Dunphy
09/18/2025, 9:35 AMMarvin
09/18/2025, 9:35 AMMarvin
09/18/2025, 9:40 AMdeployments:
- name: run_proactive
entrypoint: orchestrator/run.py:run_proactive
work_pool:
name: Managed
steps:
pull:
# If you can provide a GH token as an env var at runtime:
- prefect.deployments.steps.utility.run_shell_script:
id: get-github-token
script: "echo ${GITHUB_TOKEN}"
expand_env_vars: true
- prefect.deployments.steps.pull.git_clone:
id: git-clone
branch: main
repository: "<https://x-access-token:{{> get-github-token.stdout }}@github.com/aidan-frntir/agentpoc.git"
- prefect.deployments.steps.utility.pip_install_requirements:
requirements_file: requirements.txt
2) Deploy from the project root with core CLI:
prefect deploy orchestrator/run.py:run_proactive -n run_proactive
3) Confirm the saved steps:
prefect deployment inspect "run_proactive/run_proactive"
There should be no uv/uvx in pull_steps.
Option B: Keep the prefect-cloud wrapper, but avoid its uv/uvx helpers
- Remove flags that cause it to inject uv/uvx steps (e.g., drop --with-requirements) and/or configure it to use pip instead of uv. If the wrapper doesn’t support that, prefer Option A.
- Alternatively, you’d have to ensure uv/uvx exist on the worker image — not feasible with Managed infra.
About “Managed infra doesn’t reference my prefect.yaml”
- Managed vs Docker/K8s only determines how the run is executed. The deployment’s pull_steps always run on the worker, regardless of infra type.
- Whether your deployment uses prefect.yaml depends on how the deployment was created:
- core prefect deploy: uses your project’s prefect.yaml
- the prefect-cloud wrapper: generates its own steps (what you’re seeing now)
Next actions I recommend
- Recreate the deployment with core prefect deploy and the YAML above (pip_install_requirements + git_clone), pass GITHUB_TOKEN as an env var when you trigger runs or set it in job variables for the deployment.
- Or, if you want to keep using the wrapper, share the exact flags you need and I can suggest the closest equivalent without injecting uv/uvx.
References
- Prefect YAML guide: prefect.yaml guide
- CLI reference: prefect deploy CLI
If you want, paste your current prefect.yaml and confirm how you want to provide the GitHub token (env var, Secret block, or Prefect Variable), and I’ll give you a drop-in YAML that avoids uv/uvx.Aidan Dunphy
09/18/2025, 9:43 AMMarvin
09/18/2025, 9:43 AMMarvin
09/18/2025, 9:44 AMprefect deployment inspect "<old-flow>/<old-deployment>"
prefect deployment inspect "<new-flow>/<new-deployment>"
If the old one lacks the uvx step (or shows pip instead of uv), that’s your smoking gun.
- Also check when the deployment was last “updated” vs when your failures started.
A robust path forward (recap)
- Stop relying on the wrapper’s injected steps; define explicit, uv-free steps and deploy with core CLI:
deployments:
- name: run_proactive
entrypoint: orchestrator/run.py:run_proactive
work_pool:
name: Managed
steps:
pull:
- prefect.deployments.steps.pull.git_clone:
id: git-clone
branch: main
repository: "<https://github.com/aidan-frntir/agentpoc.git>"
access_token: "{{ prefect.variables.GITHUB_TOKEN }}" # or env/Secret
- prefect.deployments.steps.utility.pip_install_requirements:
requirements_file: requirements.txt
Then:
prefect deploy orchestrator/run.py:run_proactive -n run_proactive
- Or, use code-based storage so no shell token dance is needed:
from prefect import flow
flow.from_source(
"<https://github.com/aidan-frntir/agentpoc>",
entrypoint="orchestrator/run.py:run_proactive",
credentials={"access_token": "<read from Prefect Variable/Secret>"},
).deploy(name="run_proactive", work_pool_name="Managed")
- If you insist on the wrapper, drop flags that cause it to inject “uvx …”/“uv pip …”, or confirm it supports a “use pip” mode. Otherwise you’d have to bake uv/uvx into the worker image, which isn’t possible with Managed.
Happy to help translate your current deploy into a prefect.yaml with:
- git_clone using access_token (from Prefect Variable/Secret or env var)
- pip_install_requirements
- any env/secrets/parameters you pass today via CLI flags
Refs:
- Prefect YAML guide: prefect.yaml guide
- Deploy CLI: prefect deploy CLI