Context:
The version_parse crate attempts to parse a url to provide a project, version and release-series e.g.
"https://download.gnome.org/sources/gnome-disk-utility/46/gnome-disk-utility-46.1.tar.xz",
Extraction {
version: "46.1".to_owned(),
name: "gnome-disk-utility".to_owned(),
release_series: Some("46".to_owned()),
},
This is used by boulder auto-update functionality to guess new urls for new releases
boulder new functionality looks at the url given to it and attempts to match it against known providers in boulder/src/draft/metadata
e.g.
fn test_regex_typical_pypi_url() {
let url_str = "https://files.pythonhosted.org/packages/59/83/a60af4e83c492c7dceceeabd677aa87bbaf2d8910b3d1b973295e560f421/pyzk-0.9.tar.gz";
let url = Url::parse(url_str).unwrap();
let source = source(&url);
assert!(source.is_some());
let source = source.unwrap();
assert_eq!(source.name, "python-pyzk");
assert_eq!(source.version, "0.9");
assert_eq!(source.homepage, "https://pypi.org/project/pyzk");
assert_eq!(
source.uri,
"https://files.pythonhosted.org/packages/source/p/pyzk/pyzk-0.9.tar.gz"
);
}
This is used for writing a stone.yaml recipe file from a url, attempting to pre-fill some fields correctly.
As you can see both codepaths are attempting to do similar but subtly different things.
Current issues:
version_parse uses a series of complex regexes that are difficult to maintain and occasionally have issues successfully parsing upstream urls e.g. see #799 #811 #793 #786.
Potential solution:
Consolidate boulder new and version_parse functionality into a small crate of known provider urls e.g. github/gitlab/pypi/etc and only fall back to the regexes for unknown urls
For example
pub struct UpstreamProvider {
pub name: String,
pub version: String,
pub release_series: Some(String),
pub homepage: Some(String),
pub uri: String,
}
By building up a series of known provider urls we can consolidate the functionality as well as hopefully reduce tricky issues where version_parse was failing to parse various urls.
Context:
The
version_parsecrate attempts to parse a url to provide a project, version and release-series e.g.This is used by boulder auto-update functionality to guess new urls for new releases
boulder newfunctionality looks at the url given to it and attempts to match it against known providers inboulder/src/draft/metadatae.g.
This is used for writing a
stone.yamlrecipe file from a url, attempting to pre-fill some fields correctly.As you can see both codepaths are attempting to do similar but subtly different things.
Current issues:
version_parseuses a series of complex regexes that are difficult to maintain and occasionally have issues successfully parsing upstream urls e.g. see #799 #811 #793 #786.Potential solution:
Consolidate
boulder newandversion_parsefunctionality into a small crate of known provider urls e.g. github/gitlab/pypi/etc and only fall back to the regexes for unknown urlsFor example
By building up a series of known provider urls we can consolidate the functionality as well as hopefully reduce tricky issues where version_parse was failing to parse various urls.