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>
jrray
force-pushed
the
pin-with-pre-and-post
branch
from
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.
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.
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.
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: truedoes not do that. UsingfromBuildEnv: ==x.x.xdoes not render any pre- or post-release components. Now it is possible
to put
fromBuildEnv: ==Vwhich would render into, e.g.,==1.2.3+r.1.