zenml-nightly 0.82.1.dev20250522__tar.gz → 0.82.1.dev20250524__tar.gz

zenml_nightly-0.82.1.dev20250524/AGENTS.md

@@ -0,0 +1,237 @@
+# ZenML Codex Agent Guidelines
+
+This document provides guidance for Codex agents working with the ZenML codebase. ZenML is an extensible, open-source MLOps framework for creating production-ready ML pipelines.
+
+## Project Structure
+
+- `/src/zenml/` - Core source code
+- `/tests/` - Test suite (unit, integration)
+- `/docs/` - Documentation
+- `/examples/` - Example projects (IMPORTANT: Do not modify directly - this folder is updated by CI from other repositories)
+- `/scripts/` - Development utilities
+
+Use filesystem navigation tools to explore the codebase structure as needed.
+
+## Code Style & Quality Standards
+
+### Formatting and Linting
+- Format code with: `bash scripts/format.sh` (requires Python environment with dev dependencies)
+  - Run this before every commit to ensure proper formatting
+  - Automatically fixes and formats code using ruff and yamlfix
+- Check code quality with: `bash scripts/lint.sh`
+  - Unlike format.sh, this doesn't auto-fix issues
+  - Runs mypy type checking on the codebase
+  - Note: Full mypy check is slow on the entire codebase
+  - For faster checks, run mypy directly on specific files: `mypy src/zenml/path/to/file.py`
+- The primary code style is enforced by ruff, configured in `pyproject.toml`
+- YAML formatting uses yamlfix: `yamlfix .github -v`
+
+### Python Standards
+- Use Python 3.9+ compatible code
+- Follow Google Python style for docstrings
+- Type hint all function parameters and return values
+- Use descriptive variable names and documentation
+- Keep function size manageable (aim for < 50 lines) though there are exceptions
+
+### Testing Requirements
+- Most new code requires test coverage
+  - Key exceptions are when the code involves integrations with external
+    services. (in those cases we generally test things extensively locally and
+    in the CI. So the developer might have to run things or set things up
+    locally first.)
+- Tests live in the `/tests/` folder with structure loosely mirroring the main codebase
+- Unit tests go in `/tests/unit/`
+- Integration tests go in `/tests/integration/`
+
+#### Running Tests
+- Do NOT try to run the entire test suite locally - many tests require special environments
+- Run targeted tests for the specific components you've changed:
+  - `pytest tests/unit/path/to/test_file.py`
+  - `pytest tests/unit/path/to/test_file.py::test_specific_function`
+- For full coverage, use CI (see CI section below)
+- Some tests use: `bash scripts/test-coverage-xml.sh` (but this won't run all tests)
+
+## Development Workflow
+
+### Prerequisites
+- Set up a Python environment with ZenML dev dependencies
+- Install ZenML in development mode: `pip install -e ".[dev]"`
+- Most scripts require these dependencies to be available
+- ZenML recommends using `uv` for Python package installation in local environments
+  - `uv` is also used in CI workflows
+  - It resolves dependencies more quickly and reliably than pip
+  - It can resolve dependency conflicts that pip sometimes struggles with or takes a long time to resolve
+
+### Environment Variables
+- Several environment variables are useful during ZenML development:
+  - `ZENML_DEBUG=true`: Enables verbose debug logging
+  - `ZENML_LOGGING_VERBOSITY=INFO`: Controls logging verbosity
+  - `ZENML_ANALYTICS_OPT_IN=false`: Disables analytics during development
+  - `MLSTACKS_ANALYTICS_OPT_OUT=true`: Disables MLStacks analytics
+  - `AUTO_OPEN_DASHBOARD=false`: Prevents automatic dashboard opening
+  - `ZENML_ENABLE_RICH_TRACEBACK=false`: Disables rich traceback formatting
+  - `TOKENIZERS_PARALLELISM=false`: Avoids tokenizers parallelism warnings
+
+### Branch Management
+- **IMPORTANT**: `develop` is our primary working branch, NOT `main`
+- Always branch off `develop` for all changes
+- All PRs should target the `develop` branch
+- The `main` branch is only updated during the release process
+- If working on a feature branch that's already based on `develop`, you may need to branch off that feature branch for related changes
+
+### Making Changes
+1. Run `bash scripts/format.sh` before every commit
+2. Run targeted tests to verify changes (see above)
+3. Update documentation for user-facing changes (or ensure that nothing was broken)
+
+### Security Guidelines
+- **NEVER** commit secrets, API keys, tokens, or passwords
+- Use environment variables or ZenML's secret management for sensitive data
+- Review changes for accidental credential exposure before committing
+- If you accidentally commit secrets, notify the team immediately
+- Follow the principle of least privilege when implementing access controls
+- Validate and sanitize all user inputs
+
+### Database and Migration Guidelines
+- Database schema changes require Alembic migrations
+- Create migrations with descriptive names: `alembic revision -m "Add X to Y table"`
+- Test migrations both up and down: `alembic upgrade head` and `alembic downgrade -1`
+- Never modify existing migrations that are already on main/develop branches
+- Always consider backward compatibility for rolling deployments
+- Include both schema changes and data migrations when needed
+- Run `scripts/check-alembic-branches.sh` to verify migration consistency
+
+### Commit Message Guidelines
+- Write clear, descriptive commit messages explaining the "why" not just the "what"
+- First line should be a concise summary (50 chars or less)
+- Use imperative mood: "Add feature" not "Added feature"
+- Reference issue numbers when applicable: "Fix user auth bug (#1234)"
+- For multi-line messages, add a blank line after the summary
+- Example:
+  ```
+  Add retry logic to artifact upload
+  
+  Previously, artifact uploads would fail immediately on network errors.
+  This adds exponential backoff retry logic to handle transient failures.
+  
+  Fixes #1234
+  ```
+
+### When Implementing Features
+- Study existing similar implementations first
+- Follow the established patterns in the codebase
+- Keep backward compatibility in mind
+- Add appropriate error handling
+- Document public APIs thoroughly
+
+### When Fixing Bugs
+- Add regression tests that would have caught the bug
+- Understand root cause before implementing fix
+- Document the fix in commit messages
+
+### Pull Request Guidelines
+- Use human-readable names for PRs (no prefixes like "feat:" or "doc:")
+- Keep PR titles concise but descriptive
+- Write comprehensive PR descriptions:
+  - Clearly explain what the changes do
+  - Mention why the changes are needed
+  - Detail any important implementation decisions
+  - Note any areas that need special reviewer attention
+- Detailed PR descriptions help both reviewers and release note creation
+- Use appropriate PR tags where applicable:
+  - `internal`: For changes relevant only to ZenML team members
+  - `documentation`: For changes related to documentation
+  - `bug`: For bug fixes
+  - `dependencies`: For dependency updates
+  - `enhancement`: For new features or improvements
+
+### Continuous Integration
+- ZenML uses a two-tier CI approach:
+  - **Fast CI**: Runs automatically on all PRs (basic tests, linting, type checking)
+  - **Full CI**: Includes integration tests and more extensive test coverage
+- The `run-slow-ci` label triggers full CI testing
+- Full CI is required before merging - maintainers will add the label if needed
+- If your changes touch integrations or core functionality, mention in the PR that full CI should be run
+- CI failures will show in the PR checks - review logs to understand any issues
+
+## Core Concepts
+
+### Important Terminology
+- The term "model" has multiple distinct meanings in the codebase:
+  1. **Pydantic models**: Data structures used throughout the codebase (like `PipelineModel`)
+  2. **ML models**: Actual machine learning models (PyTorch, sklearn, etc.)
+  3. **ZenML models**: Namespaces that group artifacts, metadata, and other resources related to an ML model
+- Be careful with these terms when reading/writing code to avoid confusion
+
+### Pipeline Architecture
+- Pipelines are collections of steps
+- Steps produce and consume artifacts
+- Artifacts are serialized/deserialized by materializers
+- Pipelines are executed by orchestrators
+- Stack components provide functionality like storage, orchestration, etc.
+
+### Key Abstractions
+- `BaseComponent` - Base for stack components
+- `BasePipeline` - Pipeline definition
+- `BaseStep` - Step implementation
+- `BaseMaterializer` - Artifact serialization
+- `BaseOrchestrator` - Pipeline execution
+
+## Common Tasks
+
+### Adding New Integrations
+1. Create integration package in `/src/zenml/integrations/`
+2. Implement required abstractions and register flavors
+3. Add tests in `/tests/integrations/`
+4. Add documentation in `/docs/book/component-guide/`
+
+### Modifying Core Functionality
+1. Understand the impact on existing components
+2. Maintain backward compatibility where possible
+3. Add comprehensive test coverage
+4. Update type hints and documentation
+
+## Task Planning Approach
+
+When tackling complex tasks:
+1. Break down the task into smaller sub-tasks
+2. Research existing implementations in the codebase
+3. Plan approach before implementation
+4. Test incrementally as you implement
+5. Document design decisions in code comments
+
+## Expert Tips
+
+- ZenML follows a plugin architecture - study how components are registered
+- API stability is important - don't break public interfaces
+- Review similar PRs for implementation patterns
+- Pipeline execution is complex - test thoroughly when modifying
+
+## Documentation Guidelines
+
+### Structure
+- Documentation files live in `docs/book/`
+- Multiple sections each have their own `toc.md` file for navigation
+- Assets (images, etc.) belong in a `.gitbook` folder at the same level as the relevant `toc.md`
+- When adding or removing pages, update the appropriate `toc.md` file
+
+### Format and Style
+- ZenML uses GitBook for documentation
+- Include metadata fields at the top of documentation pages (follow existing patterns)
+- Documentation should be readable and conversational
+- Use consistent formatting with existing documentation
+- Avoid overusing bullet points or other formatting elements
+- Prioritize readability and clarity over excessive structure
+- Include appropriate cross-references to related documentation
+
+### Content Standards
+- Clear, concise language
+- Code examples for APIs
+- Explanation of concepts
+- Usage patterns and best practices
+- Match tone and style with existing documentation
+
+---
+
+*This document is maintained to help Codex agents work effectively with the
+ZenML codebase. For human contributors, see CONTRIBUTING.md.*

zenml_nightly-0.82.1.dev20250524/CLAUDE.md

@@ -0,0 +1,237 @@
+# ZenML Claude Code Guidelines
+
+This document provides guidance for Claude Code when working with the ZenML codebase. ZenML is an extensible, open-source MLOps framework for creating production-ready ML pipelines.
+
+## Project Structure
+
+- `/src/zenml/` - Core source code
+- `/tests/` - Test suite (unit, integration)
+- `/docs/` - Documentation
+- `/examples/` - Example projects (IMPORTANT: Do not modify directly - this folder is updated by CI from other repositories)
+- `/scripts/` - Development utilities
+
+Use filesystem navigation tools to explore the codebase structure as needed.
+
+## Code Style & Quality Standards
+
+### Formatting and Linting
+- Format code with: `bash scripts/format.sh` (requires Python environment with dev dependencies)
+  - Run this before every commit to ensure proper formatting
+  - Automatically fixes and formats code using ruff and yamlfix
+- Check code quality with: `bash scripts/lint.sh`
+  - Unlike format.sh, this doesn't auto-fix issues
+  - Runs mypy type checking on the codebase
+  - Note: Full mypy check is slow on the entire codebase
+  - For faster checks, run mypy directly on specific files: `mypy src/zenml/path/to/file.py`
+- The primary code style is enforced by ruff, configured in `pyproject.toml`
+- YAML formatting uses yamlfix: `yamlfix .github -v`
+
+### Python Standards
+- Use Python 3.9+ compatible code
+- Follow Google Python style for docstrings
+- Type hint all function parameters and return values
+- Use descriptive variable names and documentation
+- Keep function size manageable (aim for < 50 lines) though there are exceptions
+
+### Testing Requirements
+- Most new code requires test coverage
+  - Key exceptions are when the code involves integrations with external
+    services. (in those cases we generally test things extensively locally and
+    in the CI. So the developer might have to run things or set things up
+    locally first.)
+- Tests live in the `/tests/` folder with structure loosely mirroring the main codebase
+- Unit tests go in `/tests/unit/`
+- Integration tests go in `/tests/integration/`
+
+#### Running Tests
+- Do NOT try to run the entire test suite locally - many tests require special environments
+- Run targeted tests for the specific components you've changed:
+  - `pytest tests/unit/path/to/test_file.py`
+  - `pytest tests/unit/path/to/test_file.py::test_specific_function`
+- For full coverage, use CI (see CI section below)
+- Some tests use: `bash scripts/test-coverage-xml.sh` (but this won't run all tests)
+
+## Development Workflow
+
+### Prerequisites
+- Set up a Python environment with ZenML dev dependencies
+- Install ZenML in development mode: `pip install -e ".[dev]"`
+- Most scripts require these dependencies to be available
+- ZenML recommends using `uv` for Python package installation in local environments
+  - `uv` is also used in CI workflows
+  - It resolves dependencies more quickly and reliably than pip
+  - It can resolve dependency conflicts that pip sometimes struggles with or takes a long time to resolve
+
+### Environment Variables
+- Several environment variables are useful during ZenML development:
+  - `ZENML_DEBUG=true`: Enables verbose debug logging
+  - `ZENML_LOGGING_VERBOSITY=INFO`: Controls logging verbosity
+  - `ZENML_ANALYTICS_OPT_IN=false`: Disables analytics during development
+  - `MLSTACKS_ANALYTICS_OPT_OUT=true`: Disables MLStacks analytics
+  - `AUTO_OPEN_DASHBOARD=false`: Prevents automatic dashboard opening
+  - `ZENML_ENABLE_RICH_TRACEBACK=false`: Disables rich traceback formatting
+  - `TOKENIZERS_PARALLELISM=false`: Avoids tokenizers parallelism warnings
+
+### Branch Management
+- **IMPORTANT**: `develop` is our primary working branch, NOT `main`
+- Always branch off `develop` for all changes
+- All PRs should target the `develop` branch
+- The `main` branch is only updated during the release process
+- If working on a feature branch that's already based on `develop`, you may need to branch off that feature branch for related changes
+
+### Making Changes
+1. Run `bash scripts/format.sh` before every commit
+2. Run targeted tests to verify changes (see above)
+3. Update documentation for user-facing changes (or ensure that nothing was broken)
+
+### Security Guidelines
+- **NEVER** commit secrets, API keys, tokens, or passwords
+- Use environment variables or ZenML's secret management for sensitive data
+- Review changes for accidental credential exposure before committing
+- If you accidentally commit secrets, notify the team immediately
+- Follow the principle of least privilege when implementing access controls
+- Validate and sanitize all user inputs
+
+### Database and Migration Guidelines
+- Database schema changes require Alembic migrations
+- Create migrations with descriptive names: `alembic revision -m "Add X to Y table"`
+- Test migrations both up and down: `alembic upgrade head` and `alembic downgrade -1`
+- Never modify existing migrations that are already on main/develop branches
+- Always consider backward compatibility for rolling deployments
+- Include both schema changes and data migrations when needed
+- Run `scripts/check-alembic-branches.sh` to verify migration consistency
+
+### Commit Message Guidelines
+- Write clear, descriptive commit messages explaining the "why" not just the "what"
+- First line should be a concise summary (50 chars or less)
+- Use imperative mood: "Add feature" not "Added feature"
+- Reference issue numbers when applicable: "Fix user auth bug (#1234)"
+- For multi-line messages, add a blank line after the summary
+- Example:
+  ```
+  Add retry logic to artifact upload
+  
+  Previously, artifact uploads would fail immediately on network errors.
+  This adds exponential backoff retry logic to handle transient failures.
+  
+  Fixes #1234
+  ```
+
+### When Implementing Features
+- Study existing similar implementations first
+- Follow the established patterns in the codebase
+- Keep backward compatibility in mind
+- Add appropriate error handling
+- Document public APIs thoroughly
+
+### When Fixing Bugs
+- Add regression tests that would have caught the bug
+- Understand root cause before implementing fix
+- Document the fix in commit messages
+
+### Pull Request Guidelines
+- Use human-readable names for PRs (no prefixes like "feat:" or "doc:")
+- Keep PR titles concise but descriptive
+- Write comprehensive PR descriptions:
+  - Clearly explain what the changes do
+  - Mention why the changes are needed
+  - Detail any important implementation decisions
+  - Note any areas that need special reviewer attention
+- Detailed PR descriptions help both reviewers and release note creation
+- Use appropriate PR tags where applicable:
+  - `internal`: For changes relevant only to ZenML team members
+  - `documentation`: For changes related to documentation
+  - `bug`: For bug fixes
+  - `dependencies`: For dependency updates
+  - `enhancement`: For new features or improvements
+
+### Continuous Integration
+- ZenML uses a two-tier CI approach:
+  - **Fast CI**: Runs automatically on all PRs (basic tests, linting, type checking)
+  - **Full CI**: Includes integration tests and more extensive test coverage
+- The `run-slow-ci` label triggers full CI testing
+- Full CI is required before merging - maintainers will add the label if needed
+- If your changes touch integrations or core functionality, mention in the PR that full CI should be run
+- CI failures will show in the PR checks - review logs to understand any issues
+
+## Core Concepts
+
+### Important Terminology
+- The term "model" has multiple distinct meanings in the codebase:
+  1. **Pydantic models**: Data structures used throughout the codebase (like `PipelineModel`)
+  2. **ML models**: Actual machine learning models (PyTorch, sklearn, etc.)
+  3. **ZenML models**: Namespaces that group artifacts, metadata, and other resources related to an ML model
+- Be careful with these terms when reading/writing code to avoid confusion
+
+### Pipeline Architecture
+- Pipelines are collections of steps
+- Steps produce and consume artifacts
+- Artifacts are serialized/deserialized by materializers
+- Pipelines are executed by orchestrators
+- Stack components provide functionality like storage, orchestration, etc.
+
+### Key Abstractions
+- `BaseComponent` - Base for stack components
+- `BasePipeline` - Pipeline definition
+- `BaseStep` - Step implementation
+- `BaseMaterializer` - Artifact serialization
+- `BaseOrchestrator` - Pipeline execution
+
+## Common Tasks
+
+### Adding New Integrations
+1. Create integration package in `/src/zenml/integrations/`
+2. Implement required abstractions and register flavors
+3. Add tests in `/tests/integrations/`
+4. Add documentation in `/docs/book/component-guide/`
+
+### Modifying Core Functionality
+1. Understand the impact on existing components
+2. Maintain backward compatibility where possible
+3. Add comprehensive test coverage
+4. Update type hints and documentation
+
+## Task Planning Approach
+
+When tackling complex tasks:
+1. Break down the task into smaller sub-tasks
+2. Research existing implementations in the codebase
+3. Plan approach before implementation
+4. Test incrementally as you implement
+5. Document design decisions in code comments
+
+## Expert Tips
+
+- ZenML follows a plugin architecture - study how components are registered
+- API stability is important - don't break public interfaces
+- Review similar PRs for implementation patterns
+- Pipeline execution is complex - test thoroughly when modifying
+
+## Documentation Guidelines
+
+### Structure
+- Documentation files live in `docs/book/`
+- Multiple sections each have their own `toc.md` file for navigation
+- Assets (images, etc.) belong in a `.gitbook` folder at the same level as the relevant `toc.md`
+- When adding or removing pages, update the appropriate `toc.md` file
+
+### Format and Style
+- ZenML uses GitBook for documentation
+- Include metadata fields at the top of documentation pages (follow existing patterns)
+- Documentation should be readable and conversational
+- Use consistent formatting with existing documentation
+- Avoid overusing bullet points or other formatting elements
+- Prioritize readability and clarity over excessive structure
+- Include appropriate cross-references to related documentation
+
+### Content Standards
+- Clear, concise language
+- Code examples for APIs
+- Explanation of concepts
+- Usage patterns and best practices
+- Match tone and style with existing documentation
+
+---
+
+*This document is maintained to help Claude Code work effectively with the
+ZenML codebase. For human contributors, see CONTRIBUTING.md.*

{zenml_nightly-0.82.1.dev20250522 → zenml_nightly-0.82.1.dev20250524}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.3
 Name: zenml-nightly
-Version: 0.82.1.dev20250522
+Version: 0.82.1.dev20250524
 Summary: ZenML: Write production-ready ML code.
 License: Apache-2.0
 Keywords: machine learning,production,pipeline,mlops,devops

{zenml_nightly-0.82.1.dev20250522 → zenml_nightly-0.82.1.dev20250524}/pyproject.toml

@@ -1,6 +1,6 @@
 [tool.poetry]
 name = "zenml-nightly"
-version = "0.82.1.dev20250522"
+version = "0.82.1.dev20250524"
 packages = [{ include = "zenml", from = "src" }]
 description = "ZenML: Write production-ready ML code."
 authors = ["ZenML GmbH <info@zenml.io>"]

zenml_nightly-0.82.1.dev20250524/src/zenml/VERSION

@@ -0,0 +1 @@
+0.82.1.dev20250524

{zenml_nightly-0.82.1.dev20250522 → zenml_nightly-0.82.1.dev20250524}/src/zenml/client.py

@@ -2024,7 +2024,9 @@ class Client(metaclass=ClientMetaClass):
             name=name,
             type=component_type,
             flavor=flavor,
-            configuration=configuration,
+            configuration=validated_config.model_dump(
+                mode="json", exclude_unset=True
+            ),
             labels=labels,
         )
 
@@ -2112,7 +2114,9 @@ class Client(metaclass=ClientMetaClass):
             assert validated_config is not None
             warn_if_config_server_mismatch(validated_config)
 
-            update_model.configuration = existing_configuration
+            update_model.configuration = validated_config.model_dump(
+                mode="json", exclude_unset=True
+            )
 
         if labels is not None:
             existing_labels = component.labels or {}

{zenml_nightly-0.82.1.dev20250522 → zenml_nightly-0.82.1.dev20250524}/src/zenml/config/docker_settings.py

@@ -386,6 +386,31 @@ class DockerSettings(BaseSettings):
 
         return self
 
+    @model_validator(mode="before")
+    @classmethod
+    @before_validator_handler
+    def _warn_about_future_default_installer(
+        cls, data: Dict[str, Any]
+    ) -> Dict[str, Any]:
+        """Warns about the future change of default package installer from pip to uv.
+
+        Args:
+            data: The model data.
+
+        Returns:
+            The validated settings values.
+        """
+        if "python_package_installer" not in data:
+            logger.warning(
+                "In a future release, the default Python package installer "
+                "used by ZenML to build container images for your "
+                "containerized pipelines will change from 'pip' to 'uv'. "
+                "To maintain current behavior, you can explicitly set "
+                "`python_package_installer=PythonPackageInstaller.PIP` "
+                "in your DockerSettings."
+            )
+        return data
+
     model_config = ConfigDict(
         # public attributes are immutable
         frozen=True,

{zenml_nightly-0.82.1.dev20250522 → zenml_nightly-0.82.1.dev20250524}/src/zenml/config/server_config.py

@@ -45,6 +45,7 @@ from zenml.constants import (
     DEFAULT_ZENML_SERVER_MAX_REQUEST_BODY_SIZE_IN_BYTES,
     DEFAULT_ZENML_SERVER_NAME,
     DEFAULT_ZENML_SERVER_PIPELINE_RUN_AUTH_WINDOW,
+    DEFAULT_ZENML_SERVER_REQUEST_TIMEOUT,
     DEFAULT_ZENML_SERVER_SECURE_HEADERS_CACHE,
     DEFAULT_ZENML_SERVER_SECURE_HEADERS_CONTENT,
     DEFAULT_ZENML_SERVER_SECURE_HEADERS_CSP,
@@ -252,6 +253,11 @@ class ServerConfiguration(BaseModel):
             used.
         file_download_size_limit: The maximum size of the file download in
             bytes. If not specified, the default value of 2GB will be used.
+        thread_pool_size: The size of the thread pool for handling requests. If
+            not specified, the default value of 40 will be used.
+        server_request_timeout: The timeout for server requests in seconds. If
+            not specified, the default value of 20 seconds will be used. This
+            value should be lower than the client's request timeout.
     """
 
     deployment_type: ServerDeploymentType = ServerDeploymentType.OTHER
@@ -348,6 +354,7 @@ class ServerConfiguration(BaseModel):
     auto_activate: bool = False
 
     thread_pool_size: int = DEFAULT_ZENML_SERVER_THREAD_POOL_SIZE
+    server_request_timeout: int = DEFAULT_ZENML_SERVER_REQUEST_TIMEOUT
 
     max_request_body_size_in_bytes: int = (
         DEFAULT_ZENML_SERVER_MAX_REQUEST_BODY_SIZE_IN_BYTES

{zenml_nightly-0.82.1.dev20250522 → zenml_nightly-0.82.1.dev20250524}/src/zenml/constants.py

@@ -282,6 +282,7 @@ DEFAULT_ZENML_SERVER_MAX_DEVICE_AUTH_ATTEMPTS = 3
 DEFAULT_ZENML_SERVER_DEVICE_AUTH_TIMEOUT = 60 * 5  # 5 minutes
 DEFAULT_ZENML_SERVER_DEVICE_AUTH_POLLING = 5  # seconds
 DEFAULT_HTTP_TIMEOUT = 30
+DEFAULT_ZENML_SERVER_REQUEST_TIMEOUT = 20  # seconds
 SERVICE_CONNECTOR_VERIFY_REQUEST_TIMEOUT = 120  # seconds
 ZENML_API_KEY_PREFIX = "ZENKEY_"
 DEFAULT_ZENML_SERVER_PIPELINE_RUN_AUTH_WINDOW = 60 * 48  # 48 hours

{zenml_nightly-0.82.1.dev20250522 → zenml_nightly-0.82.1.dev20250524}/src/zenml/enums.py

@@ -314,6 +314,7 @@ class EnvironmentType(StrEnum):
     LIGHTNING_AI_STUDIO = "lightning_ai_studio"
     GITHUB_CODESPACES = "github_codespaces"
     VSCODE_REMOTE_CONTAINER = "vscode_remote_container"
+    ZENML_CODESPACE = "zenml_codespace"
 
 
 class ModelStages(StrEnum):

{zenml_nightly-0.82.1.dev20250522 → zenml_nightly-0.82.1.dev20250524}/src/zenml/environment.py

@@ -79,6 +79,8 @@ def get_environment() -> str:
         return EnvironmentType.GENERIC_CI
     elif Environment.in_github_codespaces():
         return EnvironmentType.GITHUB_CODESPACES
+    elif Environment.in_zenml_codespace():
+        return EnvironmentType.ZENML_CODESPACE
     elif Environment.in_vscode_remote_container():
         return EnvironmentType.VSCODE_REMOTE_CONTAINER
     elif Environment.in_lightning_ai_studio():
@@ -254,6 +256,16 @@ class Environment(metaclass=SingletonMetaClass):
             or "GITHUB_CODESPACES_PORT_FORWARDING_DOMAIN" in os.environ
         )
 
+    @staticmethod
+    def in_zenml_codespace() -> bool:
+        """If the current Python process is running in ZenML Codespaces.
+
+        Returns:
+            `True` if the current Python process is running in ZenML Codespaces,
+            `False` otherwise.
+        """
+        return os.environ.get("ZENML_ENVIRONMENT") == "codespace"
+
     @staticmethod
     def in_vscode_remote_container() -> bool:
         """If the current Python process is running in a VS Code Remote Container.

{zenml_nightly-0.82.1.dev20250522 → zenml_nightly-0.82.1.dev20250524}/src/zenml/integrations/gcp/__init__.py

@@ -45,7 +45,7 @@ class GcpIntegration(Integration):
     NAME = GCP
     REQUIREMENTS = [
         "kfp>=2.6.0",
-        "gcsfs",
+        "gcsfs!=2025.5.0,!=2025.5.0.post1",
         "google-cloud-secret-manager",
         "google-cloud-container>=2.21.0",
         "google-cloud-artifact-registry>=1.11.3",

{zenml_nightly-0.82.1.dev20250522 → zenml_nightly-0.82.1.dev20250524}/src/zenml/integrations/gcp/service_connectors/gcp_service_connector.py

@@ -78,7 +78,7 @@ from zenml.service_connectors.service_connector import (
 from zenml.utils.enum_utils import StrEnum
 from zenml.utils.pydantic_utils import before_validator_handler
 from zenml.utils.secret_utils import PlainSerializedSecretStr
-from zenml.utils.time_utils import utc_now
+from zenml.utils.time_utils import to_utc_timezone, utc_now
 
 logger = get_logger(__name__)
 
@@ -1200,14 +1200,13 @@ class GCPServiceConnector(ServiceConnector):
         elif auth_method == GCPAuthenticationMethods.OAUTH2_TOKEN:
             assert isinstance(cfg, GCPOAuth2TokenConfig)
 
-            expires_at = self.expires_at
-            if expires_at:
-                # Remove the UTC timezone
-                expires_at = expires_at.replace(tzinfo=None)
-
             credentials = gcp_credentials.Credentials(
                 token=cfg.token.get_secret_value(),
-                expiry=expires_at,
+                # Currently GCP expects the expiry to be a timezone-naive
+                # UTC datetime.
+                expiry=to_utc_timezone(self.expires_at).replace(tzinfo=None)
+                if self.expires_at
+                else None,
                 scopes=scopes,
             )
 
@@ -1303,10 +1302,12 @@ class GCPServiceConnector(ServiceConnector):
                 )
 
         if credentials.expiry:
-            # Add the UTC timezone to the expiration time
-            expires_at = credentials.expiry.replace(
-                tzinfo=datetime.timezone.utc
-            )
+            expires_at = credentials.expiry
+
+        if expires_at:
+            # Add the UTC timezone to the expiration time, if it's not already
+            # set
+            expires_at = to_utc_timezone(expires_at)
 
         return credentials, expires_at