Skip to content

Backport/main post v0.22.0 to next#2950

Open
huitseeker wants to merge 7 commits intonextfrom
backport/main-post-v0.22.0-to-next
Open

Backport/main post v0.22.0 to next#2950
huitseeker wants to merge 7 commits intonextfrom
backport/main-post-v0.22.0-to-next

Conversation

@huitseeker
Copy link
Copy Markdown
Contributor

Merges main back into next.

This also keeps the main behavior for preassembled packages with kernel runtime dependencies. Package resolution keeps the kernel requirement, prefers the stored kernel when present, falls back to a matching embedded kernel when needed, and rejects bad or conflicting embedded kernel metadata. See 88af767 individually.

@huitseeker huitseeker added the no changelog This PR does not require an entry in the `CHANGELOG.md` file label Mar 31, 2026
bitwalker and others added 4 commits March 31, 2026 06:32
Update MAST package structure for project assembly
processor: expose advice, memory and transcript
Keep runtime dependencies from preassembled packages in dependency resolution.
Programs that declare a kernel now require the matching kernel package when they are rebuilt.
The resolver prefers the stored kernel, falls back to a matching embedded kernel, and rejects bad or conflicting embedded kernel metadata.
@0xMiden 0xMiden deleted a comment from github-actions bot Mar 31, 2026
@huitseeker huitseeker force-pushed the backport/main-post-v0.22.0-to-next branch from 88af767 to b40e5e9 Compare March 31, 2026 10:35
@huitseeker huitseeker marked this pull request as ready for review March 31, 2026 11:01
Copy link
Copy Markdown
Collaborator

@bitwalker bitwalker left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it probably would be best to address the packaging/project assembly issues as a separate PR(s) (see #2944 for the tracking issue created for this purpose).

I think raising an error if an executable package doesn't have an embedded kernel is probably fine. I'm less sure about the other change to the dependency graph - or at least, I think a different approach might ultimately be better for resolving the issue around source packages failing to rebuild due to missing dependencies in the registry (see my other comments for details).

Could we perhaps remove that latter change, but keep the rejection of executables with no embedded kernel, and then address the other issue separately as a follow-on? Definitely feel free to add another sub-issue to #2944 if none of those existing issues covers what you were aiming to fix here.

.map_err(|error| Report::msg(error.to_string()))?;
}

for node in graph.nodes.values() {
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We only embed the kernel into executable packages - and executable packages can't be dependencies. In all other cases, we treat the dependency on a kernel like any other dependency - we can select any kernel version so long as it satisfies the version requirements of all the dependents.


let record = PackageRecord::new(kernel_version, kernel_requirements);
registry
.insert_record(kernel_package.name.clone(), record)
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is inserting the embedded kernel into the registry, but I don't think we should be doing that - the kernel by definition would have needed to be a dependency in the graph, so there should already be a node corresponding to what was declared in the package manifest. If there isn't, something else is wrong.

See #2946 for how I propose we address the issue that I believe you are aiming to address here (though correct me if I'm wrong on that point).

Preassembled packages still need their runtime dependencies during resolution. Programs that need a kernel now fail when that kernel cannot be resolved, instead of silently falling back to embedded metadata during dependency selection.
@huitseeker huitseeker force-pushed the backport/main-post-v0.22.0-to-next branch from 6e485a1 to 6811ce7 Compare April 1, 2026 15:51
@0xMiden 0xMiden deleted a comment from github-actions bot Apr 1, 2026
@huitseeker
Copy link
Copy Markdown
Contributor Author

OK, I scaled this back @bitwalker :

  • A preassembled package now keeps its runtime kernel requirement in the normal dependency graph, and assembly fails if that kernel is not actually available.
  • If its pinned metadata no longer matches what the graph selected, we reject it instead of silently using drifted metadata.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

no changelog This PR does not require an entry in the `CHANGELOG.md` file

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants