Stable Composer installs for the SDK
Getting lookout/tracing to install cleanly from a split mirror repo — version constraints, stability flags, and the path-repo trick for local development.
Paired with API-only mode, today's other commit: enable stable Composer installs for lookout/tracing.
Yesterday's CI work splits the PHP SDK out to its own mirror repo. But "it's in a repo" and "people can actually composer require it" are different milestones, and the gap between them is full of Composer's least favorite words: stability and constraints.
The stability trap
When a package only has dev branches and no stable tags, Composer refuses to install it under default settings — you get the dreaded "could not find a version ... matching your minimum-stability" error. The auto-tagging from yesterday helps (every push gets a tag), but I also had to make sure the package's own composer.json declares sane version metadata so a normal composer require lookout/tracing resolves to a real, stable tag instead of demanding @dev.
Path repos for local dev
The other half: developing the SDK against a real app without publishing a version for every change. The answer is a Composer path repository — point a sample app's composer.json at the local package directory, and Composer symlinks it in. Edit the SDK, refresh the app, no publish step. (I'll lean on this hard later when I build sample apps to exercise each SDK.)
Why obsess over this on day eight
Because the SDK is the product surface for most users. They'll never see my Blade templates or my Livewire components. They'll see composer require lookout/tracing, and if that one command is rough, the whole thing feels rough. The install command is the first impression.
That wraps the foundation sprint. The app has auth, orgs, projects, ingest, an SDK that installs, and CI that ships itself. Then... life happened, and the project went quiet for a while. The next entry picks it back up.