-
Notifications
You must be signed in to change notification settings - Fork 11
Indexes 2: Add new_unchecked() constructors to spk schema objects
#1337
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from all commits
6bde293
fc04793
46c9480
ae936f5
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -392,6 +392,12 @@ impl Version { | |
| } | ||
| } | ||
|
|
||
| /// Make a new Version from a string without checking it. | ||
| /// | ||
| pub fn new_from_version_str(version_str: &str) -> Result<Self> { | ||
| Version::try_from(version_str) | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Same thought here, really unsafe?
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. To add to this, the followup question would be could the current users of
Collaborator
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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
Collaborator
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I've taken the unsafe out.
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. As above, remove the safety notice and rename to something that doesn't use "unchecked".
Collaborator
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I've updated this. |
||
| } | ||
|
|
||
| /// The major version number (first component) | ||
| pub fn major(&self) -> u32 { | ||
| self.parts.first().copied().unwrap_or_default() | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -104,6 +104,32 @@ impl EmbeddedPackageSpec { | |
| } | ||
| } | ||
|
|
||
| /// Create a spec for the identified package from the given values | ||
| /// without checking them. | ||
| /// | ||
| /// # Safety | ||
| /// | ||
| /// The caller must make sure the pieces combine to make a valid | ||
| /// EmbeddedPackageSpec. | ||
|
Comment on lines
+112
to
+113
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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.
Collaborator
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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? |
||
| pub unsafe fn new_unchecked( | ||
| ident: BuildIdent, | ||
| build: EmbeddedBuildSpec, | ||
| requirements_with_options: RequirementsList<RequestWithOptions>, | ||
| install: EmbeddedInstallSpec, | ||
| ) -> Self { | ||
| EmbeddedPackageSpec { | ||
| pkg: ident, | ||
| meta: Meta::default(), | ||
| compat: Compat::default(), | ||
| deprecated: bool::default(), | ||
| sources: Vec::new(), | ||
| build, | ||
| tests: Vec::new(), | ||
| install, | ||
| install_requirements_with_options: requirements_with_options, | ||
| } | ||
| } | ||
|
|
||
| /// Read-only access to the build spec | ||
| #[inline] | ||
| pub fn build(&self) -> &EmbeddedBuildSpec { | ||
|
|
||
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No
new_checked()methods were added for these String based types here. But in a later indexes PRs there are several uses ofunsafe { ... }around an existing method on these types. It may be we want to fold those into anew_unchecked()method for non-test cases use.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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).