Conversation
12e0b36 to
136f95d
Compare
|
FWIW with the increased complexity, and increased clarity on how the regex string works - I would be more happy now to make a well defined |
136f95d to
39ef733
Compare
abderrahim
left a comment
There was a problem hiding this comment.
This works fine, but I still think it's a bit too complicated.
I feel that extracting the basename from the URL and using just that for guessing the version is good enough. I went through all the buildstream projects I work on and couldn't find any instance where the version isn't in the basename.
That said, I won't block this.
This is implicitly required by adding the 2.5.0.dev0 tag.
This is public, and is used in buildstream-plugins-community, but this was documented as an internal buildstream function.
This defines the API contract which a plugin has with the user who provides a regular expression for version guessing. This is a superior implementation to what we initially landed in the downloadable file source, and addresses cases where a match could be found multiple times, such as: https://example.com/releases/1.2/release-1.2.3.tgz
39ef733 to
15e9f77
Compare
I have now:
|
This fixes the issue of parsing typically formulated release tarball URLs.
Consider the URL
https://flying-ponies.com/releases/1.2/pony-flight-1.2.3.tgz.Without this change, we only get the version
1.2(the directory where we put all of the1.2releases).After this change, we get
1.2.3.This is achieved by explicitly supporting optional groups in the regex (which we already did, but in an not very specified way), and preferring more qualified matches by preferring matches which had more groups present in the match while iterating over all non-overlapping matches.
By causing the user to explicitly specify groups in the regex, we avoid the pitfall of relying on silly things like string length (where both strings "1.200" and "1.2.3" would be considered equally qualified).