Skip to content

feat: Add buildable giskard meta-package and release workflow support#2404

Merged
kevinmessiaen merged 12 commits into
mainfrom
feat/release-workflow-giskard-3
Jun 23, 2026
Merged

feat: Add buildable giskard meta-package and release workflow support#2404
kevinmessiaen merged 12 commits into
mainfrom
feat/release-workflow-giskard-3

Conversation

@kevinmessiaen

Copy link
Copy Markdown
Member

Description

Add buildable giskard meta-package and release workflow support in order to allow installing Giskard packages using pip install giskard

Comment thread .github/workflows/release.yml Fixed
Comment thread .github/workflows/release.yml Fixed
Comment thread .github/workflows/release.yml Fixed

@gemini-code-assist gemini-code-assist Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request introduces a giskard_pypi_shim module and configures the build system using hatchling in pyproject.toml to facilitate a meta-distribution. Feedback suggests ensuring the LICENSE file is included in the source distribution and removing the ignore-vcs setting to avoid including unintended local files.

Comment thread pyproject.toml Outdated
kevinmessiaen and others added 4 commits June 15, 2026 10:34
Bump giskard to 3.0.0b1 and giskard-checks to expose an `all` extra.
Restructure root optional-dependencies into named provider/checks/scan
extras with an aggregated `full` target, and switch the dev group to
giskard[full]. Fix invalid TOML in the `full` extra (missing quotes).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Reduce the "Resolve package paths" step to a single `dir` output and
derive pyproject/dist paths inline at each consumer. Also fix a
double-space typo in the all-checks extra.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The giskard-llm version floors (>=1.0.1b3) were unsatisfiable from PyPI:
giskard-llm is published at 1.0.0b4, and per PEP 440 1.0.0b4 < 1.0.1b3.
This broke `pip install giskard[openai|google|anthropic|all-llms|full]`
for end users; the uv workspace masked it via editable installs.

- Lower openai/google/anthropic/all-llms floors to >=1.0.0b4
- Point azure extra at giskard-llm[azure] to track its upstream alias
  instead of the self-referential giskard[openai]
- Clean dist/ before uv build in the release workflow

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
kevinmessiaen and others added 4 commits June 23, 2026 20:14
# Conflicts:
#	pyproject.toml
#	uv.lock
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Newer openai/anthropic SDKs added error classes with constructor
signatures that don't accept (message, response, body) -- e.g.
openai.OAuthError and anthropic.APIWebhookValidationError. Build the
exception kwargs from the constructor signature instead of hard-coding
them, so the mapping-completeness tests survive SDK upgrades.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Development

Successfully merging this pull request may close these issues.

3 participants