Proposal: Refactor Provider API to inject a storage directory

[rhuss]

Our current provider configurations in templates use absolute paths (e.g., ~/.llama/distributions/...) for storage locations, creating a tight coupling between configuration and deployment environment. This makes e.g. containerized deployments, particularly in Kubernetes, unnecessarily complex as we need to map those paths to something else as a directory within the home directory (which is also not super well-defined when running in containers and depends how you've built your distribution container)

E.g currently in templates we have

providers:
  vector_io:
  - provider_id: sqlite-vec
    provider_type: inline::sqlite-vec
    config:
      db_path: ${env.SQLITE_STORE_DIR:~/.llama/distributions/verification}/sqlite_vec.db

Proposed Change:
We should modify the Provider API to accept a storage_dir during instantiation, allowing providers to resolve relative paths from their configuration. This would transform the above into:

providers:
  vector_io:
  - provider_id: sqlite-vec
    provider_type: inline::sqlite-vec
    config:
      db_path: sqlite_vec.db  # Relative path

This change would significantly improve our deployment flexibility. In Kubernetes, for example, we could simply mount a persistent volume to the distribution storage directory without complex path mapping. But also in other environments like Windows, where the notion of a Home directory is not so straight forward, or when people want to leverage an external storage for the inline provider data, this might be helpful. One could add a cli option and/or environment variable to point to this storage directory (much like today's SQLITE_STORE_DIR, but no need to add those directly to the templates, which makes it hard to maintain, too, as the pathes also encapsulate distribution names)

It would also make our configurations more portable across environments and easier to version control, as they'd no longer contain environment-specific absolute paths.

The implementation would need to maintain backward compatibility while providing clear documentation and validation for the new relative path pattern. We should also consider how this affects existing deployments and what migration strategy would be appropriate. Backwards compatibility could work by just checking whether the configured path is a relative (new way) or an absolute path.

The provider change could look like

# Current Provider API
class Provider:
    def __init__(self, config: Dict[str, Any]):
        self.config = config
        self.db_path = config.get('db_path')  # Absolute path

# Proposed Provider API
class Provider:
    def __init__(self, config: Dict[str, Any], storage_dir: Path):
        self.config = config
        self.storage_dir = storage_dir
        self.db_path = self._resolve_path(config.get('db_path'))

    def _resolve_path(self, path: Union[str, Path]) -> Path:
        path = Path(path)
        if path.is_absolute():
            return path
        return self.storage_dir / path

Would appreciate thoughts on this approach and if this makes sense.

[liangwen12year]

It makes perfect sense to me, shifting to a storage_dir based resolution clearly increases portability, container‑friendliness, at the cost of API/CLI churning and the need for careful documentation on the changes. As long as we can provide sane defaults, clear documentation, and deprecation warnings for existing absolute‑path users, the long‑term maintenance and operational simplicity gains will far outweigh the up‑front effort.

[ashwinb]

Seems reasonable to me. The one downside is that is all of the providers are now forced to be within one top level storage_dir -- this might be a fine restriction to have, but just noting that.