Does the latest prefect version have any issues for others? My pipelines are all failing about a prefect dependency, griffe, not having a dataclasses module.

Traceback (most recent call last):
  File "/builds/arenko-group/infra/data-account/scripts/create_resources.py", line 6, in <module>
    from prefect.blocks.system import Secret
  File "/venv/lib/python3.12/site-packages/prefect/__init__.py", line 30, in <module>
    from prefect.deployments import deploy
  File "/venv/lib/python3.12/site-packages/prefect/deployments/__init__.py", line 1, in <module>
    import prefect.deployments.base
  File "/venv/lib/python3.12/site-packages/prefect/deployments/base.py", line 22, in <module>
    from prefect.client.schemas.objects import MinimalDeploymentSchedule
  File "/venv/lib/python3.12/site-packages/prefect/client/schemas/__init__.py", line 4, in <module>
    from .actions import BlockTypeUpdate, StateCreate
  File "/venv/lib/python3.12/site-packages/prefect/client/schemas/actions.py", line 7, in <module>
    from prefect._internal.compatibility.deprecated import DeprecatedInfraOverridesField
  File "/venv/lib/python3.12/site-packages/prefect/_internal/compatibility/deprecated.py", line 28, in <module>
    from prefect.utilities.callables import get_call_parameters
  File "/venv/lib/python3.12/site-packages/prefect/utilities/callables.py", line 27, in <module>
    from griffe.dataclasses import Docstring
ModuleNotFoundError: No module named 'griffe.dataclasses'

downgrade griffe to version 0.49.0 and it should work

Ah perfect, glad this is known even though apparently my google-fu skills are terrible and I missed that issue. Will pin it to 0.49.0, thanks all

The real question here is why isn't prefect pinning the versions of all of their dependencies rather than leaving it up to users to fix.

As Prefect is a framework, it's important that we support as diverse a development environment for users as possible which typically means not prematurely pinning dependencies. The few times we have done this, we inadvertently mess up a different group of users (just a quick search of our GitHub issues reveals many examples of this issue, e.g., https://github.com/PrefectHQ/prefect/issues/2910). It's generally best practice that applications built with a framework own the responsibility for managing their own environment and pinning their dependencies. It's a delicate balance for sure.

Also: pinning dependencies has pretty rough security implications (pinning to a version with a CVE) and compatibility implications (if we pin a package you explicitly use to a version less than you want to use, then we’d brick you). All that aside, we depend on our dependencies (what a phrase) to follow OSS standards like SemVer so that we can depend on minor versions to not have breaking API changes. We had one dependency break this convention, and it’ll result in us taking a serious look at removing it.

Although you can make a case for pinning the major version? But it is a rabbit hole

Yea pinning the major version definitely makes sense - i think

griffe

had an inconsistency between client / server dependencies that resulted in 1.0 getting through