Skip to content

multi-valued variants comparison fix#5593

Closed
scheibelp wants to merge 3 commits intospack:developfrom
scheibelp:bugfix/multivalued-variant-compare
Closed

multi-valued variants comparison fix#5593
scheibelp wants to merge 3 commits intospack:developfrom
scheibelp:bugfix/multivalued-variant-compare

Conversation

@scheibelp
Copy link
Copy Markdown
Member

Fixes #5587

@alalazo, @tgamblin

While debugging #5587 I noticed the following:

(Pdb) x = spec.copy(deps=('link', 'run'))
(Pdb) x
    [email protected]%[email protected] patches=88dfefa6d39c9fd5a26a40d9bbc73df8da93f946c65c06038026261d78d919f5,dfd62a42a239c427bb44087b4a520edbcd65bae6ad1fbe07303c96ee8696afbd arch=linux-rhel6-x86_64 ^[email protected]%[email protected] arch=linux-rhel6-x86_64
(Pdb) installed_spec
    [email protected]%[email protected] patches=dfd62a42a239c427bb44087b4a520edbcd65bae6ad1fbe07303c96ee8696afbd,88dfefa6d39c9fd5a26a40d9bbc73df8da93f946c65c06038026261d78d919f5 arch=linux-rhel6-x86_64 ^[email protected]%[email protected] arch=linux-rhel6-x86_64

And noticed the patches are differently-ordered in the two specs, which led me to look at _cmp_key for variants. It looks like multi-valued variants arbitrarily order their values which was resulting in a failed comparison.

This is hackish and WIP but demonstrates the issue.

@scheibelp
Copy link
Copy Markdown
Member Author

This fails for python 3.x since basestring is not there apparently but this still illustrates the problem and passes for 2.x

@scheibelp
Copy link
Copy Markdown
Member Author

I have re-implemented this in terms of method overrides

@alalazo
Copy link
Copy Markdown
Member

alalazo commented Oct 4, 2017

@scheibelp

It looks like multi-valued variants arbitrarily order their values which was resulting in a failed comparison

I don't think that's true: it would have failed way before if that was the behavior, and there's a test here to check that ordering is not arbitrary + what you do in this PR is already done in the value setter.

The problem seems instead to be that in #5476 we started setting private members directly, without sorting their arguments. I refer to this line in the current code. I'll try to submit a patch for that.

alalazo added a commit to epfl-scitas/spack that referenced this pull request Oct 4, 2017
refers spack#5587
closes spack#5593

The implementation introduced in spack#5476 used `dedupe` to set a private
member of a `MultiValuedVariant` object. `dedupe` is meant to give a
stable deduplication of the items in a sequence, and returns an object
whose value depends on the order of items in its argument.

Now the private member is set implicitly using the associated property
setter. The logic changes from stable deduplication to a totally ordered
deduplication (i.e. instead of `dedupe(t)` it uses `sorted(set(t))`).
This should also grant that packages that shuffle the same set of
patch directives maintain the same hash.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants