add VersionMap helper

[dhellmann]

Resolves #489

[rd4398]

This looks good!

[prarit]

@dhellmann I think there's a minor error in the lookup() code. See 7749583 . I'm testing a patch right now.

[dhellmann]

@dhellmann I think there's a minor error in the lookup() code. See 7749583 . I'm testing a patch right now.

@prarit I'm not quite sure I understand, but I think the tests here and here demonstrate that a requirement without a version specifier works with and without constraints.

If I'm wrong, could you add a comment to the tests with an assert that would fail?

[dhellmann]

I added a test for the flag for allowing pre-release versions.

[prarit]

@dhellmann I think there's a minor error in the lookup() code. See 7749583 . I'm testing a patch right now.

@prarit I'm not quite sure I understand, but I think the tests here and here demonstrate that a requirement without a version specifier works with and without constraints.

If I'm wrong, could you add a comment to the tests with an assert that would fail?

So it's not the check as I thought but an issue with existing version maps in builder. The aotriton versionmap can be tested as:

`def test_with_constraint_fails():

m = VersionMap({Version("0.4.1b0"): "0.4.1b", Version("0.6b0"): "0.6b"})
assert m.lookup(Requirement("pkg"), Requirement("pkg<0.6b0")) == "0.4.1b0"
`
which will fail as the lookup() call returns "0.4.1b", not 0.4.1b0 as the current builder:package_plugins/utils.py:resolve_specifier() does. It seems that the versionmap for aotriton is valid. Let's discuss in the AM :)

[edit: I should add, the difference between the string and the Version in the VersionMap is intentional. The Version refers to the python package name, and the string refers to the github tarball name. Setting allow_prerelease=True does not seem to help. We could (should?) perhaps separate the builder python package and tarball name mapping into their own maps as a solution.]

[edit2 post workout clarity: Another solution here is to write a builder helper function in package_plugins/utils.py that 'does the right thing' and creates a versionmap with matching values to pass into the fromager code. That seems way easier and smarter IMO. That way there's no rewriting of builder code Version usage. Let me code that in the AM. It's a bit late now. Hope you're okay with the delay @dhellmann ]

[dhellmann]

`def test_with_constraint_fails():

m = VersionMap({Version("0.4.1b0"): "0.4.1b", Version("0.6b0"): "0.6b"}) assert m.lookup(Requirement("pkg"), Requirement("pkg<0.6b0")) == "0.4.1b0" ` which will fail as the lookup() call returns "0.4.1b", not 0.4.1b0 as the current builder:package_plugins/utils.py:resolve_specifier() does. It seems that the versionmap for aotriton is valid. Let's discuss in the AM :)

[edit: I should add, the difference between the string and the Version in the VersionMap is intentional. The Version refers to the python package name, and the string refers to the github tarball name. Setting allow_prerelease=True does not seem to help. We could (should?) perhaps separate the builder python package and tarball name mapping into their own maps as a solution.]

The map doesn't do the same thing as the resolver function. The resolver tells you a version that matches. The map figures that value out, then returns the corresponding value in the dictionary.

I've changed the API to return both the version and the value, and updated the test content to make it clearer which is which.

[rd4398]

This looks good!