-
Notifications
You must be signed in to change notification settings - Fork 5
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
Expand the templating language used by pinning #1024
Conversation
The nom parser handles the ambiguity of a string with multiple post release components versus multiple filters, as in: 1.2.3+a.1,b.1,<2.0 This would fail to parse with the old code. Something like this could appear in a `fromBuildEnv:` value. Signed-off-by: J Robert Ray <jrray@jrray.org>
Support esoteric use cases by giving control over whether pre- or post- release components are added to the rendered pin, or more straighforwardly, allow 'v' or 'V' to be used to expand the base version or full version of the target package, respectively. For example, say you want to create an install requirement that will exactly match the version of a package used at build time. Using `fromBuildEnv: true` does not do that. Using `fromBuildEnv: ==x.x.x` does not render any pre- or post-release components. Now it is possible to put `fromBuildEnv: ==V` which would render into, e.g., `==1.2.3+r.1`. Signed-off-by: J Robert Ray <jrray@jrray.org>
96fdbc8
to
8894a64
Compare
('x', ScannerMode::Base) => { | ||
rendered.extend(digits.next().unwrap().to_string().chars()); | ||
} | ||
('x', ScannerMode::Pre) => { |
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.
Note I intentionally make it an error to try to use x
in pre/post position because it is foolish to try to predict how many pre/post release components your build environment is going to end up with. One of the other new tokens is likely a better choice, or the recipe author can simply hard code versions instead of using a template if they are explicitly pinning the build requirement to some fixed version.
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.
Another pitfall is if there are multiple post-release components the iteration order may be not be the order expected, since it is alphabetical but still legal to write them out of sorted order.
Some even more complicated grammar is needed to handle weird edge cases but there is no user demand for this behavior. I don't think multiple post-release components have been used in practice.
| fromBuildEnv | _str_ or _bool_ | Either true, or a template to generate this request from using the version of the package that was resolved into the build environment. See [FromBuildEnvTemplate](#frombuildenvtemplate) for more information. | | ||
| ifPresentInBuildEnv | _bool_ | Either true or false; if true, then `fromBuildEnv` only applies if the package was present in the build environment. This allows different variants to have different runtime requirements. | | ||
|
||
##### FromBuildEnvTemplate |
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.
Do anchors work with deeper titles? I didn't see any existing ones that go deeper than 4 hashes.
Support esoteric use cases by giving control over whether pre- or post-
release components are added to the rendered pin, or more
straighforwardly, allow 'v' or 'V' to be used to expand the base version
or full version of the target package, respectively.
For example, say you want to create an install requirement that will
exactly match the version of a package used at build time. Using
fromBuildEnv: true
does not do that. UsingfromBuildEnv: ==x.x.x
does not render any pre- or post-release components. Now it is possible
to put
fromBuildEnv: ==V
which would render into, e.g.,==1.2.3+r.1
.