Indexes 2: Add `new_unchecked()` constructors to spk schema objects by dcookspi · Pull Request #1337 · spkenv/spk

dcookspi · 2026-03-19T22:01:04Z

Note: for info on benefits of indexing for spk solves see #1340 (5 of 5). Maybe start there and work back down to this PR if you prefer to review PRs top down.

This adds new_unchecked() constructor methods to various spk schema objects. These allow direct creation of those objects from other existing object pieces, e.g. from other pieces of those objects in index data. This is one of the changes that supports adding indexes and index based packages to Spk repositories. It allows indexes to avoid reparsing data from text for some objects.

This is 2 of 5 chained PRs for adding indexes to spk solves:

dcookspi · 2026-03-19T22:10:07Z

        }

-        // Allow tests to manufacture owned instances with known good values.
+        // Allow tests and indexes to manufacture owned instances with known good values.


No new_checked() methods were added for these String based types here. But in a later indexes PRs there are several uses of unsafe { ... } around an existing method on these types. It may be we want to fold those into a new_unchecked() method for non-test cases use.

Big picture I think we want to be able to say that values in the index were already validated before put into the index and therefore should be trusted without having to re-validate them when reading the index.

However we need a way to introduce changes to spk that may change validation rules. For example let's say we stop allowing '-' in package names. How do we want to put some kind of version number in the index metadata so at runtime the spk process can check that the index conforms to its expectations?

I'm interested in having a way to validate the whole index at once, in a sense, instead of having to validate every individual value found in the index.

I've added unsafe's to the new_checked methods and updated the callers to use unsafe blocks around them.

Validating the index will be addressed in PR3 (#1338).

codecov · 2026-03-19T23:02:13Z

Codecov Report

❌ Patch coverage is 0% with 100 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
crates/spk-schema/src/option.rs	0.00%	34 Missing ⚠️
crates/spk-schema/src/component_spec.rs	0.00%	20 Missing ⚠️
crates/spk-schema/src/v0/embedded_package_spec.rs	0.00%	18 Missing ⚠️
...hema/crates/foundation/src/ident_build/build_id.rs	0.00%	5 Missing ⚠️
...schema/crates/foundation/src/version/compat/mod.rs	0.00%	4 Missing ⚠️
...-schema/crates/foundation/src/version_range/mod.rs	0.00%	4 Missing ⚠️
...a/crates/foundation/src/ident_ops/parsing/ident.rs	0.00%	3 Missing ⚠️
...es/spk-schema/crates/foundation/src/version/mod.rs	0.00%	3 Missing ⚠️
...ates/spk-schema/src/component_embedded_packages.rs	0.00%	3 Missing ⚠️
crates/spk-schema/src/component_spec_list.rs	0.00%	3 Missing ⚠️
... and 1 more

📢 Thoughts on this report? Let us know!

jrray

This is gonna hurt...

jrray · 2026-03-26T17:43:12Z

        }

-        // Allow tests to manufacture owned instances with known good values.
+        // Allow tests and indexes to manufacture owned instances with known good values.


Big picture I think we want to be able to say that values in the index were already validated before put into the index and therefore should be trusted without having to re-validate them when reading the index.

However we need a way to introduce changes to spk that may change validation rules. For example let's say we stop allowing '-' in package names. How do we want to put some kind of version number in the index metadata so at runtime the spk process can check that the index conforms to its expectations?

I'm interested in having a way to validate the whole index at once, in a sense, instead of having to validate every individual value found in the index.

jrray · 2026-04-02T20:24:12Z

+    /// # Safety
+    ///
+    /// The caller must ensure the string parses as a valid compat.
+    pub unsafe fn new_unchecked(compat: &str) -> Result<Self> {


This uses from_str and returns a Result. Is it really unsafe? It has to successfully parse so I don't think using this skips any validation.

I've removed the unsafe keyword for now. I'll will come back if/when the compat representations in the index change from string to an ordered list of compat rules entries - which is a possible future extension.

jrray · 2026-04-02T20:25:33Z

+    /// The caller must make sure the string can be parsed as a valid
+    /// Version.
+    pub unsafe fn new_unchecked(version_str: &str) -> Result<Self> {
+        Version::try_from(version_str)


Same thought here, really unsafe?

To add to this, the followup question would be could the current users of Version::new_unchecked just switch to Version::try_from and then this constructor is not needed?

It's not really unsafe here, I'll take it out.

For the followup question: Yes it could be replaced for this PR. But for one of the the later ones, or a coming improvement (I can't remember which, but one of them wull change the string in index storage to the component number pieces), the new_checked() implementation would change to directly set the fields in the Version struct. I suppose I could take it out and then put it back, but I wanted to put all the new_unchecked() methods in one PR.

I've taken the unsafe out.

As above, remove the safety notice and rename to something that doesn't use "unchecked".

I've updated this.

jrray · 2026-04-02T20:34:15Z

+    /// The caller must make sure the pieces combine to make a valid
+    /// EmbeddedPackageSpec.


I feel the need to say that this safety message (and the others) amount to saying "you have responsibilities to use this correctly" but without giving any details on how to use it correctly. I get it that you don't necessarily know what those are. I couldn't tell you what they are right now on the spot either.

Yes, the safety messages are a linting requirement. Looking up the specific details is very much left to the caller. I couldn't say what they are for the different cases either - other than make sure you pass valid x, y, z objects in. I suspect the actual details could be found in the parsing methods, maybe?

jrray

Typo, and maybe some things are unsafe that don't have to be.

I'm not expecting you to update the safety statements but can you create an issue for it to acknowledge it?

jrray · 2026-04-29T23:18:12Z

+    /// # Safety
+    ///
+    /// The caller must ensure the string parses as a valid compat.
+    pub fn new_unchecked(compat: &str) -> Result<Self> {


You can (should) remove the safety notice for a function that is not unsafe.

IMO new or from_compat would be a better name for this, if it is even needed at all, at least up until the point where this evolves into something that is unsafe and unchecked.

I've updated this.

jrray · 2026-04-29T23:18:47Z

+    /// The caller must make sure the string can be parsed as a valid
+    /// Version.
+    pub unsafe fn new_unchecked(version_str: &str) -> Result<Self> {
+        Version::try_from(version_str)


As above, remove the safety notice and rename to something that doesn't use "unchecked".

These allow for directly creating those objects from other existing object pieces, e.g. from index data objects. Signed-off-by: David Gilligan-Cook <dcook@imageworks.com>

Signed-off-by: David Gilligan-Cook <dcook@imageworks.com>

…s and compat. Signed-off-by: David Gilligan-Cook <dcook@imageworks.com>

dcookspi self-assigned this Mar 19, 2026

dcookspi added SPI AOI Area of interest for SPI pr-chain This PR doesn't target the main branch, don't merge! labels Mar 19, 2026

dcookspi commented Mar 19, 2026

View reviewed changes

Comment thread crates/spk-schema/crates/foundation/src/version/compat/mod.rs

dcookspi commented Mar 19, 2026

View reviewed changes

Comment thread crates/spk-schema/crates/foundation/src/version_range/mod.rs

dcookspi commented Mar 19, 2026

View reviewed changes

Comment thread crates/spk-schema/crates/foundation/src/version/compat/mod.rs Outdated

dcookspi added the enhancement New feature or request label Mar 19, 2026

dcookspi requested review from jrray and rydrman March 19, 2026 22:53

dcookspi force-pushed the index-1-package-trait-changes branch from 2f40d65 to fb6e0dd Compare March 25, 2026 00:42

dcookspi force-pushed the index-2-new-unchecked-additions branch from d83388a to a59523b Compare March 25, 2026 00:56

jrray requested changes Mar 26, 2026

View reviewed changes

dcookspi force-pushed the index-1-package-trait-changes branch from fb6e0dd to 9bd9685 Compare March 26, 2026 23:06

dcookspi force-pushed the index-2-new-unchecked-additions branch 2 times, most recently from 5c8e4db to 33938c3 Compare March 27, 2026 00:54

dcookspi mentioned this pull request Mar 30, 2026

CompatRules vs a single CompatRule - should be different types #1347

Open

dcookspi requested a review from jrray March 30, 2026 18:17

dcookspi mentioned this pull request Apr 2, 2026

Indexes 6: Changes version_filter field in index schema #1344

Open

jrray reviewed Apr 2, 2026

View reviewed changes

Comment thread crates/spk-schema/src/requirements_list.rs Outdated

jrray requested changes Apr 2, 2026

View reviewed changes

dcookspi requested a review from jrray April 7, 2026 20:20

This was referenced Apr 16, 2026

Indexes 7: Adds a lock file around index generation and updates #1354

Open

Indexes 8: Fixes the spk build or mkb crash with indexes enabled #1355

Open

dcookspi force-pushed the index-1-package-trait-changes branch from 9bd9685 to cebade9 Compare April 17, 2026 17:29

Base automatically changed from index-1-package-trait-changes to main April 17, 2026 18:14

dcookspi force-pushed the index-2-new-unchecked-additions branch from f2be50a to 54465be Compare April 17, 2026 19:20

dcookspi mentioned this pull request Apr 20, 2026

Indexes 9 - Adds messaging on package events to kafka #1356

Open

jrray requested changes Apr 29, 2026

View reviewed changes

dcookspi added 4 commits April 30, 2026 11:37

Adds new_unchecked() constructor methods to various spk schema objects.

6bde293

These allow for directly creating those objects from other existing object pieces, e.g. from index data objects. Signed-off-by: David Gilligan-Cook <dcook@imageworks.com>

Updarted new_unchecked methods to be unsafe

fc04793

Signed-off-by: David Gilligan-Cook <dcook@imageworks.com>

Removes some unsafe keywords, updated comments

46c9480

Signed-off-by: David Gilligan-Cook <dcook@imageworks.com>

Changes new_unchecked methods into new_from_*_str methods for version…

ae936f5

…s and compat. Signed-off-by: David Gilligan-Cook <dcook@imageworks.com>

dcookspi force-pushed the index-2-new-unchecked-additions branch from 54465be to ae936f5 Compare April 30, 2026 19:29

dcookspi requested a review from jrray April 30, 2026 19:43

jrray approved these changes May 4, 2026

View reviewed changes

		/// The caller must make sure the pieces combine to make a valid
		/// EmbeddedPackageSpec.

Conversation

dcookspi commented Mar 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

dcookspi Mar 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

codecov Bot commented Mar 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

jrray left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

jrray Apr 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dcookspi Apr 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

jrray left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dcookspi Apr 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

dcookspi commented Mar 19, 2026 •

edited

Loading

dcookspi Mar 19, 2026 •

edited

Loading

codecov Bot commented Mar 19, 2026 •

edited

Loading

jrray Apr 2, 2026 •

edited

Loading

dcookspi Apr 7, 2026 •

edited

Loading

jrray left a comment •

edited

Loading

dcookspi Apr 30, 2026 •

edited

Loading