Skip to content

feat: Read the graph and install a core from the command line - #1

Merged
nfebe merged 6 commits into
mainfrom
feat/read-the-graph-and-install-a-core
Aug 30, 2026
Merged

feat: Read the graph and install a core from the command line#1
nfebe merged 6 commits into
mainfrom
feat/read-the-graph-and-install-a-core

Conversation

@nfebe

@nfebe nfebe commented Aug 30, 2026

Copy link
Copy Markdown
Contributor

The command a person types. It lists the repositories this machine covers, prints what the code graph holds for one of them, opens the view in a browser, and installs a core to answer all of it.

A core runs in a container, so the repositories it indexes have to be visible from inside one. Paths it is given are mounted rather than assumed.

Checks run for the first time here: formatting, vet, tests under the race detector, and a build. The targets are the ones already in the Makefile, so what runs here is what runs when somebody runs it themselves.

Companion to sourceant/sourceant#128, sourceant/design#1 and sourceant/agent#1, all merged.

nfebe added 6 commits August 28, 2026 21:34
The command a person types. It asks the agent what is indexed on this
machine and what the indexer found in one repository, and prints a count by
kind and by edge, which is what a terminal can say about a graph it cannot
draw. Anything that would rather read the answer than look at it asks for
JSON and gets the agent's own.

It talks only to the agent, never past it to the indexer: the agent is the
half that is always up and the half that knows where the indexer landed, so
reaching around it would mean learning both. An agent that is not running is
reported as what to do about it rather than as a socket error.
Adds ui, which points a browser at the view the agent serves. It asks the
agent first, so an agent that is not running is a line saying so rather than
a browser landing on an error page. --no-open prints the address for anyone
who would rather open it themselves.
Adds install, which is what makes the agent runnable by somebody who is not
already set up to run the core by hand. It puts a core on this machine and
writes down which one, so the agent knows what to start.

Two ways to have it, chosen at install time. A container, which is what
exists today. Or a Python program, for when the core is published as a
package: until then that path says so plainly and points at the one that
works, rather than recording a runtime that would fail to start later.

Both put the index in the same place, so it does not matter which one built
it, and a container runs as whoever installed so what it writes there belongs
to them.
A container that can only see the index reads no files, so an install now
records a directory to make visible and the agent mounts it at the path it
already has on this machine. Your home, which is where repositories nearly
always are; one outside it is not readable this way.
The targets are the ones in the Makefile, so what runs here is what runs
when somebody runs it themselves.
The ignore pattern for the built binary was unanchored, so it matched the
command directory as well and the entry point was never committed. A
fresh clone could not build.
@nfebe
nfebe merged commit 71c0de0 into main Aug 30, 2026
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant