Metadata-Version: 2.4
Name: cf-setup
Version: 0.1.7
Summary: Manifest-driven Cogniflow workspace setup orchestration
Requires-Python: >=3.11
Description-Content-Type: text/markdown
Requires-Dist: cf-service-contracts>=0.1.0
Requires-Dist: packaging>=24
Provides-Extra: test
Requires-Dist: pytest<9.0,>=8.0; extra == "test"
Requires-Dist: rdflib>=7; extra == "test"
Requires-Dist: pyarrow>=18; extra == "test"

# cf-setup

`cf-setup` is the first-party setup orchestrator for the Cogniflow Windows workspace.

It centralizes:

- module and profile definitions
- deterministic install planning
- PyPI vs local-build vs editable source decisions
- Windows prerequisite diagnostics
- delegated native or frontend build steps
- post-install hooks
- structured installation reporting

Typical usage:

```powershell
py -3.14 -m cf_setup plan --profile core --format json
py -3.14 -m cf_setup diagnose --provider windows --format json
py -3.14 -m cf_setup install --dev --profile full --editable cf-pipeline-engine
py -3.14 -m cf_setup incremental --module cf-basic-io --smoke
```

The dedicated bootstrap entrypoint is `cf-setup-bootstrap ...`; it bootstraps Python and delegates orchestration into `cf_setup`.

`cf_setup` now supports two practical modes:

- repository mode: used by the local `cf_setup` bootstrap and workspace maintainers
- distribution mode: used when `cf install` runs without a repository checkout and must rely on packaged manifest resources plus published package artifacts

For repository users, the recommended public-facing workflow is now `pip install cogniflow` followed by `cf install --dev`. Internally, `--dev` is a CLI alias for repository mode.

In distribution mode, `cf install` now also prepares the user workspace under `~/.cogniflow/workspace` by default, initializes the semantics store files, and runs installed-step ingestion so the environment is usable immediately after setup.

`cf install --run-demo` in distribution mode now runs a small published demo from packaged `cf-setup` demo resources. The demo uses the same semantics-runtime discovery and ingestion framework that loads packaged ontology N-Quads and installed step packages into the workspace store, rather than a separate legacy demo path.

## Incremental Development

The `cf_setup` bootstrap remains the hard full-reset bootstrap and demo gate when you need a repo-local entrypoint.

For faster local iteration, `cf_setup incremental` updates only the requested first-party module scope plus its `compile` and `tooling` prerequisites:

```powershell
py -3.14 -m cf_setup incremental --module cf-basic-io --smoke
py -3.14 -m cf_setup incremental --module cf-package-contracts --run-demo
```

Key behavior:

- no factory reset
- no global uninstall of all managed packages
- same native toolchain environment as the full installer
- `pip check` still runs
- installed-step ingestion still runs when step packages are in scope
- `--run-demo` remains optional and reuses the maintained semantics-runtime demo path

## Publishing

`cf-setup` is prepared for the dedicated Windows workflow:

- Workflow: `.github/workflows/cf_setup_windows_publish.yml`
- Package directory: `sandcastle/cf_setup`
- PyPI tag: `cf-setup-v<version>`
- TestPyPI tag: `cf-setup-v<version>-test`
- Release order: publish `cf-core-cli 0.1.5` first, then `cf-setup`, then `cf-setup-wizard`, then `cogniflow`

Local preflight:

```powershell
powershell -ExecutionPolicy Bypass -File scripts/mimic_windows_python_publish_workflow.ps1 `
  -WorkflowFile .github/workflows/cf_setup_windows_publish.yml `
  -PackageDir sandcastle/cf_setup `
  -PythonExe py `
  -PythonVersion 3.14
```

Queue a dry-run dispatch:

```powershell
powershell -ExecutionPolicy Bypass -File scripts/queue_windows_python_publish_workflow.ps1 `
  -WorkflowFile .github/workflows/cf_setup_windows_publish.yml `
  -PackageDir sandcastle/cf_setup `
  -PublishTarget testpypi `
  -Ref main `
  -RequireLocalPass `
  -DryRun `
  -ReleaseTag cf-setup-v0.1.3-test
```
