That warning is coming from Pydantic v2: you’re passing a

default

via

Field()

in a context where it’s ignored (typically inside

Annotated[...]

). You can either fix the root cause or suppress the warning. Fix (preferred): - If you’re using

Annotated

, move the default to an assignment, not into

Field()

. Example:

from typing import Annotated
from pydantic import BaseModel, Field

# Bad (triggers warning):
# timezone: Annotated[str, Field(default='UTC')]

# Good:
class Config(BaseModel):
    timezone: Annotated[str, Field(description="Time zone")] = 'UTC'

- If you’re not using

Annotated

, you can still use assignment or

Field(default=...)

directly on the model field:

class Config(BaseModel):
    timezone: str = 'UTC'  # simplest
    # or:
    # timezone: str = Field(default='UTC')

Suppress just this warning: - In code (place this early in your program/flow file):

import warnings
from pydantic.warnings import UnsupportedFieldAttributeWarning

warnings.filterwarnings("ignore", category=UnsupportedFieldAttributeWarning)

- Via environment variable (useful for Prefect workers/deployments):

export PYTHONWARNINGS="ignore::pydantic.warnings.UnsupportedFieldAttributeWarning"

Set this in the environment where your Prefect worker runs or in your deployment’s environment. - In pytest (if this is test-time noise):

# pytest.ini or pyproject.toml [tool.pytest.ini_options]
filterwarnings =
    ignore::pydantic.warnings.UnsupportedFieldAttributeWarning

References: - Python warnings docs - Pydantic v2: Fields If you can share the model/type annotation that triggers this, I can suggest the exact change to eliminate the warning without suppressing it.

Setting PYTHONWARNINGS inside your script is too late—the interpreter reads that env var at startup. By the time your code sets

os.environ["PYTHONWARNINGS"] = ...

, Pydantic has likely already been imported and the warning emitted. Do one of the following instead: Option A: Suppress via in-code filter (must run before Pydantic is imported) Place this at the very top of your entrypoint, before any import that might touch Pydantic/models:

import warnings
from pydantic.warnings import UnsupportedFieldAttributeWarning

warnings.filterwarnings("ignore", category=UnsupportedFieldAttributeWarning)

# now import the rest of your app
# import pydantic
# from my_app import ...

Option B: Suppress via interpreter startup flags or shell env - Shell env (set before starting Python):

export PYTHONWARNINGS="ignore::pydantic.warnings.UnsupportedFieldAttributeWarning"
python your_script.py

- Or use -W:

python -W "ignore::pydantic.warnings.UnsupportedFieldAttributeWarning" your_script.py

Option C (Prefect deployments/workers): set the env on the job/worker, not inside the flow - In prefect.yaml for your deployment:

deployments:
  - name: my-deployment
    work_pool:
      name: my-pool
    job_variables:
      env:
        PYTHONWARNINGS: "ignore::pydantic.warnings.UnsupportedFieldAttributeWarning"

- Or in code when deploying:

flow.from_source("...").deploy(
  name="my-deployment",
  work_pool_name="my-pool",
  job_variables={"env": {"PYTHONWARNINGS": "ignore::pydantic.warnings.UnsupportedFieldAttributeWarning"}}
)

- Or set it as a default env var on the work pool so it applies to all jobs. Docs: Customize job variables If this still doesn’t quiet the warnings, can you share where you’re setting the env/filter relative to your imports (and whether you’re running locally, via pytest, or in a Prefect deployment/worker)? I can suggest the exact placement.

Yes—set it on the container process so Python sees it at startup. Docker Compose (recommended):

services:
  devcontainer:
    build: .
    environment:
      PYTHONWARNINGS: "ignore::pydantic.warnings.UnsupportedFieldAttributeWarning"
    # ... other service config

Then

docker compose up --build

(or restart) so the change takes effect. Alternatively, bake it into the image:

# Dockerfile
ENV PYTHONWARNINGS="ignore::pydantic.warnings.UnsupportedFieldAttributeWarning"

If this is a Prefect worker container, set it on that service:

services:
  prefect-worker:
    image: prefecthq/prefect:3-latest
    command: prefect worker start -p my-pool
    environment:
      PYTHONWARNINGS: "ignore::pydantic.warnings.UnsupportedFieldAttributeWarning"

VS Code Dev Containers: - In devcontainer.json you can also use:

"containerEnv": {
  "PYTHONWARNINGS": "ignore::pydantic.warnings.UnsupportedFieldAttributeWarning"
}

(or put it under the

environment:

for the service specified in

dockerComposeFile

). Note: you still may want an in-code safeguard at the top of your entrypoint in case the environment isn’t set in some runs:

import warnings
from pydantic.warnings import UnsupportedFieldAttributeWarning
warnings.filterwarnings("ignore", category=UnsupportedFieldAttributeWarning)

Thanks for the details — that error explains it. Why you’re seeing “Invalid -W option … invalid module name: 'pydantic.warnings'” - The `-W`/`PYTHONWARNINGS` filter tries to import the warning category class when you specify a fully-qualified category (e.g.,

pydantic.warnings.UnsupportedFieldAttributeWarning

) very early in interpreter startup. - At that moment, third‑party modules like

pydantic

may not be importable yet, so Python rejects the option. - Result: your category-based filter is ignored and the warning still prints. Two robust ways to suppress it: Option 1 (recommended): filter by message and module, no category This avoids importing third‑party code during filter parsing. - Environment variable or `-W`:

PYTHONWARNINGS="ignore:The 'default' attribute with value .* was provided to the `Field\(\)` function.*::pydantic\._internal\._generate_schema"

Notes: - Keep the two consecutive colons after the message (leaves the category blank). - Escape parentheses in

Field()

for regex. - This targets only warnings from Pydantic’s

_generate_schema

module whose message starts with “The 'default' attribute with value …”. - In code (place at the very top of your entrypoint, before anything imports Pydantic):

import warnings
warnings.filterwarnings(
    "ignore",
    message=r"The 'default' attribute with value .* was provided to the `Field\(\)` function.*",
    module=r"pydantic\._internal\._generate_schema",
)

Option 2: in-code filter using the actual warning class (only if you can run this before Pydantic is imported)

import warnings
from pydantic.warnings import UnsupportedFieldAttributeWarning

warnings.filterwarnings("ignore", category=UnsupportedFieldAttributeWarning)

If any import above this line pulls in Pydantic first, it’s too late for early warnings — so put it absolutely first. If you can fix the root cause (preferred): Move the default out of

Field()

and into the assignment (especially for

Annotated[...]

fields):

from typing import Annotated
from pydantic import BaseModel, Field

class Config(BaseModel):
    timezone: Annotated[str, Field(description="Time zone")] = "UTC"

If you’re running via Docker Compose or Prefect: - Compose:

services:
  your-service:
    environment:
      PYTHONWARNINGS: "ignore:The 'default' attribute with value .* was provided to the `Field\(\)` function.*::pydantic\._internal\._generate_schema"

- Prefect 3 deployment (prefect.yaml):

deployments:
  - name: my-deployment
    work_pool:
      name: my-pool
    job_variables:
      env:
        PYTHONWARNINGS: "ignore:The 'default' attribute with value .* was provided to the `Field\(\)` function.*::pydantic\._internal\._generate_schema"

Refs: - Python warnings filters format: Python docs: warning filter format If you paste the exact model/annotation that triggers this, I can suggest the minimal code change to remove the warning entirely.

Yes. Set PYTHONWARNINGS on the service so Python applies it at startup. To ignore all warnings coming from Pydantic (and its core lib), use module-based filters so Python doesn’t need to import Pydantic during startup. docker-compose.yml:

services:
  your-service:
    image: your-image
    environment:
      # Ignore all warnings from pydantic and pydantic_core
      PYTHONWARNINGS: "ignore:::pydantic,ignore:::pydantic_core"
    # command: python your_script.py

Notes: - The filter format is actionmessagecategorymoduleline. Leaving category blank avoids the “invalid module name” error you saw. - The module field is a regex matched from the start of the module name, so

pydantic

covers all submodules (e.g.,

pydantic._internal...

). - If you only want to ignore specific warnings later, prefer more targeted filters. Ignoring everything can hide important signals. Alternative (bake into the image):

# Dockerfile
ENV PYTHONWARNINGS="ignore:::pydantic,ignore:::pydantic_core"

If you’re running a Prefect worker inside this service, the same env var applies. Restart or rebuild the container after changing Compose.

Got it — when Prefect starts the temporary server, it spins up a separate Python process. That process must also see the warning filters at interpreter startup. If it doesn’t inherit your env or your filter is too specific, you’ll still get Pydantic warnings. Do this: 1) Use a module-only filter (no category) so Python won’t try to import Pydantic during startup - In docker-compose.yml:

services:
  your-service:
    environment:
      # Ignore all warnings from Pydantic and pydantic-core in every Python process
      PYTHONWARNINGS: "ignore:::pydantic,ignore:::pydantic_core"

- Rebuild/restart the container: docker compose up --build 2) Verify the server subprocess actually gets the env - Inside the container, run:

python -c "import os; print(os.getenv('PYTHONWARNINGS'))"

You should see: ignore::pydantic,ignore::pydantic_core 3) If warnings still appear, enforce filters via sitecustomize (bulletproof) - Add this file to your image at a location on every interpreter’s sys.path (e.g., site-packages): Dockerfile:

RUN python - <<'PY'
import site, os, sys
p = next(x for x in site.getsitepackages() if 'site-packages' in x)
os.makedirs(p, exist_ok=True)
with open(os.path.join(p, 'sitecustomize.py'), 'w') as f:
    f.write('import warnings\n'
            'warnings.filterwarnings("ignore", module=r"^pydantic(\\.|$)")\n'
            'warnings.filterwarnings("ignore", module=r"^pydantic_core(\\.|$)")\n')
print('Installed sitecustomize in', p, file=sys.stderr)
PY

This runs for every Python process automatically, including the temp server. 4) Remove any category-based filters - Make sure you’re not passing something like -W "ignore::pydantic.warnings.UnsupportedFieldAttributeWarning" anywhere; that triggers the “invalid module name” error you saw. Stick to module-only filters as above. 5) Best fix (if feasible): remove the cause - Move the default out of Field() and into the assignment for Annotated fields:

from typing import Annotated
from pydantic import BaseModel, Field

class Config(BaseModel):
    timezone: Annotated[str, Field(description="Time zone")] = "UTC"

Docs: - Python warning filters format: Python docs: warning filters - Prefect job env vars (if you deploy flows): Customize job variables If you share your compose service and how you start the flow (prefect run vs python script), I can pinpoint exactly where to place the env or add the sitecustomize in your image.

Short answer: because the -W/PYTHONWARNINGS parser treats the “category” field as an importable class. When you pass something like pydantic.warnings.UnsupportedFieldAttributeWarning, Python tries to import the module part (pydantic.warnings) at interpreter startup. If that import isn’t possible at that moment (or if you use a path that doesn’t exist like prefect.pydantic.warnings), it prints “Invalid -W option ignored: invalid module name: '…'” and ignores your filter. What to do instead - Don’t reference third‑party warning classes in -W/PYTHONWARNINGS. Use module-based filters (no category) so Python does not need to import anything during startup. Examples: - CLI:

python -W "ignore:::pydantic" -W "ignore:::pydantic_core" your_script.py

- Env var (Docker Compose, Prefect worker, etc.):

PYTHONWARNINGS="ignore:::pydantic,ignore:::pydantic_core"

- In code (if you can run this before Pydantic is imported):

import warnings
warnings.filterwarnings("ignore", module=r"^pydantic(\.|$)")
warnings.filterwarnings("ignore", module=r"^pydantic_core(\.|$)")

Why the prefect.pydantic.warnings attempt failed - There is no module named prefect.pydantic.warnings. Prefect doesn’t vend a pydantic submodule; Pydantic’s warnings live under pydantic.warnings. Docs: Python: warning filter format If you still see warnings when the temporary Prefect server starts, ensure that PYTHONWARNINGS is present in that subprocess (print it inside the container), or add a sitecustomize.py that installs the filters for every Python process automatically.