chore: drop coglet-alpha selection

[mfainberg-cf]

• Treat --x-fast / fast: true as deprecated: emit a warning and route to the standard generator instead of monobase, while explicitly defaulting cog_runtime to dataclass so “fast” users still get the dataclass SDK/runtime (pkg/dockerfile/generator_factory.go:12).
• Add a generator factory regression test that asserts the warning, standard generator selection, and dataclass runtime default when fast is requested (pkg/dockerfile/generator_factory_test.go:16).
• Fix a flaky double‑fork IPC fixture by writing .outbox atomically (.outbox.tmp + os.replace) to prevent partial reads under parallel load (integration-tests/tests/setup_subprocess_double_fork.txtar:120).
• Remove monobase‑specific txtar tests that no longer reflect supported behavior after deprecating fast/monobase:
  • integration-tests/tests/fast_build.txtar
  • integration-tests/tests/run_fast_build.txtar
  • integration-tests/tests/build_localimage.txtar
  • integration-tests/tests/predict_localimage.txtar
  • integration-tests/tests/build_base_image_sha.txtar
  • integration-tests/tests/build_cog_version_match.txtar
  • integration-tests/tests/build_python313_base_image.txtar
    Rationale
• Monobase/fast builds are being phased out; keeping the fast flag but falling back avoids breaking callers while clearly signaling deprecation.
• The double‑fork fixture race was intermittent under TEST_PARALLEL>=4 (empty .outbox), and atomic rename removes the partial‑read window without adding sleeps or changing runtime behavior.
  Testing
• script/lint
• go test ./pkg/dockerfile -run TestGeneratorFactory$
• COG_WHEEL=cog-dataclass COGLET_RUST_WHEEL=/Users/m/cf/cog2/dist/coglet-0.1.1-cp310-abi3-manylinux_2_17_x86_64.manylinux2014_x86_64.whl TEST_PARALLEL=4 COG_BINARY=/Users/m/cf/cog2/cog go test -run TestIntegration/setup_subprocess_double_fork -v (integration test; flaky on original fixture, stable with atomic outbox)

---

Extensive evaluation between coglet-alpha and the cog-dataclass python was done to determine meaningful behavioral differences. There are minor deltas that are real but for the most part will not cause breakages when someone is using cog-dataclass in lieu of coglet-alpha python code.

The high level summary is as follows:

Coglet Behavior Comparison — High-Level Summary

High-Level Summary

The two implementations are structurally similar, but not behavior-equivalent. Core differences cluster around defaults handling, error types/messages, output validation rules, and schema generation. These are likely to surface as compatibility issues if callers rely on exact error text or schema shapes.

Verdict

Close, but not interchangeable. You can treat them as conceptually similar, but exact behavior diverges in enough places to be considered breaking for strict clients.

Top Risk Areas

1. Defaults & AST validation

   • cog-runtime enforces default-None guardrails via AST checks; cog-dataclass does not.
   • cog-dataclass adds default_factory and mutable-default normalization.

2. Error types and message formats

   • cog-runtime raises AssertionError with “invalid input value …” messages.
   • cog-dataclass raises ValueError with different, often shorter, message formats.

3. Output model constraints

   • cog-runtime requires output type named Output and forbids list fields.
   • cog-dataclass allows any BaseModel name and list fields.

4. Schema generation strategy

   • cog-runtime injects Input/Output into a static OpenAPI template.
   • cog-dataclass constructs full OpenAPI schema programmatically.

The key elements to specifically highlight are:

1. This should not impact any coglet-alpha users. This is more permissive
2. These are breaking changes. IT is a relatively MINOR difference but is real. We can consider adding aliases, the stringly text should not matter
3. This is a convention, coglet-alpha users if defined as Output will see Output, we however do not enforce this
4. Byte-for-Byte schema validation is not a guarantee between cog releases

Additionally use of some long deprecated types (File) will break under cog-dataclass. This can be maintained by utilizing an older cog-sdk pre-dataclass.

[mfainberg-cf]

I'll also add the default_factory behavior will likely be no longer supported in a near-term release.

[michaeldwan]

Code seems sensible. I'd feel better if we could test this against known good models before releasing.