Add uv package manager support and project-level validator registry

[debu-sinha]

Closes #1412

What changed

This PR adds uv package manager support to Guardrails Hub and introduces a project-level JSON registry as a step toward removing the barrel __init__.py mutation pattern.

Changes

Phase 1 -- uv compatibility (this PR):

• Replace importlib.import_module('pip') with sysconfig.get_paths()['purelib'] for site-packages discovery -- eliminates the hard dependency on pip being importable
• Auto-detect uv when available via shutil.which('uv'), with GUARDRAILS_INSTALLER env var for explicit override (uv or pip)
• Add installer_process() that routes install commands through either uv pip install or python -m pip install
• Update install_hub_module() to use the detected installer

Phase 2a -- project-level registry (this PR):

• Add register_validator() that writes validator metadata to .guardrails/hub_registry.json in the project root
• Each install now writes to both the barrel __init__.py (backward compat) and the new JSON registry
• Add guardrails hub migrate CLI command that reads existing barrel imports from hub/__init__.py in site-packages and converts them to registry entries

Installer detection precedence

1. GUARDRAILS_INSTALLER=uv|pip env var (explicit override)
2. shutil.which('uv') (auto-detect)
3. Fall back to pip

Registry format

{
  "version": 1,
  "validators": {
    "guardrails/detect_pii": {
      "import_path": "guardrails_grhub_detect_pii",
      "exports": ["DetectPII"],
      "installed_at": "2025-01-01T00:00:00+00:00",
      "package_name": "guardrails-grhub-detect-pii"
    }
  }
}

How is this tested

• 35 tests in test_validator_package_service.py (all passing) -- updated existing tests to use installer_process mock, added new tests for detect_installer, get_site_packages_location, register_validator, get_registry_path
• 7 tests in test_installer_process.py (new) -- pip/uv command construction, error handling, NO_COLOR env var, empty package guard
• 6 tests in test_migrate.py (new) -- no hub init, empty init, single/multiple validator migration, multi-export lines, comment/blank line handling
• All 85 hub-related tests passing

pytest tests/unit_tests/hub/ tests/unit_tests/cli/hub/ -v
======================= 85 passed, 12 warnings in 3.70s ========================

Migration path

This is "Release A" of a two-release migration sequence:

1. Release A (this PR): Ship hub migrate + dual-write (registry + barrel). Users can opt in to the registry while barrel stays fully functional.
2. Release B (future): Switch runtime imports to read from registry first. Deprecate and eventually remove barrel file mutation.

[vercel]

@debu-sinha is attempting to deploy a commit to the Guardrails AI Team on Vercel.

A member of the Team first needs to authorize it.

[debu-sinha]

Hey @CalebCourier -- this implements the approach we discussed in #1412.

Quick summary of what's here:

• uv auto-detection: shutil.which('uv') with GUARDRAILS_INSTALLER env var override, so hub install works out of the box with uv
• sysconfig instead of pip import: no more importlib.import_module('pip') for finding site-packages
• Project-level registry: .guardrails/hub_registry.json written alongside the barrel file on every install
• hub migrate command: converts existing barrel imports to registry format for users upgrading

This is the "Release A" half -- dual-writes to both barrel and registry, nothing breaks for existing users. Happy to walk through any of it or adjust the approach.

[CalebCourier]

Thanks @debu-sinha! I repointed this from main to a version branch so that I can run our full regression test suite on it after merging [edit] before going to main.[edit] Reviewing in full now. Will keep you updated on the release cycle for this feature.

[CalebCourier]

I'm not sure this is worth including for the following reason: In order for a user to run this they would have to update the guardrails-ai package. Upon update, there will not be any entries in their hub/__init__.py. In order to repopulate it, they would need to perform the hub installs again which would automatically populate the new json registry as well.

If there's a scenario I'm not seeing where this would work please let me know but otherwise I think it's worth dropping this from the feature set.