Installation and install check¶

Release candidate, private, not published

coniti 0.1.0 is a release candidate. The wheel and source archive have been built and inspected, but nothing is published to any index, so there is nothing to pip install from outside the project. The steps below are for working on the package from its source folder.

Environment¶

coniti is developed in a conda environment named coniti, defined by environment.yml in the package folder. It uses the conda-forge channel only and is kept minimal: Python, pip and the runtime dependencies. The package itself is installed into it with pip, and pyproject.toml stays the single place where dependencies are declared.

conda env create -f environment.yml
conda activate coniti
pip install -e ".[yaml]" --group dev

Requirements: Python 3.11 or newer. Runtime dependencies are only numpy (1.26 or newer) and pydantic (v2). The optional extras are yaml, dspy, gym and testing (pytest, for the memory-backend conformance suite); --group dev adds the test and lint tools.

Check the install¶

Run either form from the activated environment:

coniti --init
python -m coniti --init

Both print an installation report and behave identically. The check only reads; it writes no files. The report lists:

the package name and version
the Python version and the path of the interpreter
the install location of the package
each runtime dependency with its version, or NOT IMPORTABLE
a list of problems, if there are any

Other commands and exit codes¶

Command	Result	Exit code
`coniti --init`	Report; installation is healthy	`0`
`coniti --init`	Report; installation is broken	`1`
`coniti --version`	Prints `coniti 0.1.0`	`0`
`coniti` (no flag)	Prints help	`0`
`coniti --unknown` (any unknown flag)	Prints usage and an error	`2`

Check from Python¶

import coniti

report = coniti.hello()
print(report.render())   # the same text that `coniti --init` prints
if not report.ok:
    print(report.problems)

coniti.hello() returns an InstallReport, a frozen dataclass. It never raises; it reports problems instead.

Field	Meaning
`ok`	`True` if there are no problems
`name`, `version`	Package identity
`python`	Python version and interpreter path
`location`	Folder the package was imported from
`dependencies`	Each runtime dependency mapped to its version, or `None` if it cannot be imported
`problems`	List of messages describing what is wrong; empty when `ok`

render() returns the human-readable report as a string.

What counts as a problem¶

A runtime dependency is missing or fails when imported.
The installed package metadata reports a different version from the imported code.
The distribution is not installed (for example, the code is imported from a source tree without installing it).
Python is older than 3.11.

InstallReport is a plain standard-library dataclass rather than a pydantic model, so the check still works, and can say so, when pydantic itself is missing.

Why the check also tests the built wheel¶

An editable install can pass while the real package is broken, for example when a module is missing from the wheel. The project’s quality gate (make check) therefore also builds the wheel and installs it, not editable, into a throwaway conda-forge environment. From outside the source tree, with a clean PATH, it runs coniti --init and import coniti; coniti.hello(), confirms the import comes from that environment, checks that the built-in kinds are discovered through the wheel’s coniti.plugins entry point, and runs a short scripted session using only the public API (ingest, ask by text and by time, remove, a gzip dump, then load_file into a new engine). It then removes everything it created. See quality.

import coniti itself needs no third-party package: the public names (such as ContinuityEngine) load lazily on first use. That is why coniti --init can still report a missing numpy or pydantic instead of failing on import.