I am sorry I missed that change earlier but it is hard to keep track, especially when you let some time go by without updating your working Spack install...

Can you be more specific on the issues that this causes for you? Wondering if it is possible to find an alternative solution.

If we refresh an existing module foo/X.Y.Z-mpi-cuda, it will create a duplicated module foo/X.Y.Z-cuda-mpi.

If we create a module for a new product, it will create a module foo/X.Y.Z-cuda-mpi while we may already have foo/I.J.K-mpi-cuda, leading to inconsistent module names.

I cannot think of any solution that would allow forcing the order to -mpi-cuda. Renaming existing module files is not something we would be happy to do as users HATE when that sort of things change as it breaks their submission scripts.

Renaming existing module files is not something we would be happy to do as users HATE when that sort of things change as it breaks their submission scripts.

Are you updating in place the Spack that is used for site-wide deployment? Would it be a solution to generate a new tree of modules at another location and provide users with a command to swap between the two?

Are you updating in place the Spack that is used for site-wide deployment?

Yeah, we already did in fact. Unfortunately I missed that issue when updating and I am only noticing it now, a few weeks after the upgrade. :/

Would it be a solution to generate a new tree of modules at another location and provide users with a command to swap between the two?

I don't really think we want to go down that road. To be honest, I think that if this PR is rejected, we will just keep the patch for our install, it will be easier for us.

Additionally I do think it is nice to be able to control the ordering of the suffixes.

@RemiLacroix-IDRIS I think you might also have missed this comment: at least at the time of that pull request, the ordering of the suffixes was unspecified: python 3.6+ kept them in the order of creation, but other versions of python shuffled them around. So the changeset you've submitted might not even get you the behavior you want.

Indeed, given that the new test I added (https://github.com/spack/spack/pull/14920/files) doesn't change behavior in your PR, I suspect this isn't doing what you want.

P.S. Is the double-hyphen in your PR description foo/X.Y.Z--cuda-mpi a typo or actually a generated module name? Because that does look like a bug that should be fixed.

P.S. Is the double-hyphen in your PR description foo/X.Y.Z--cuda-mpi a typo or actually a generated module name? Because that does look like a bug that should be fixed.

That's a typo (now fixed).

@RemiLacroix-IDRIS I think you might also have missed this comment: at least at the time of that pull request, the ordering of the suffixes was unspecified: python 3.6+ kept them in the order of creation, but other versions of python shuffled them around. So the changeset you've submitted might not even get you the behavior you want.

You are correct, it seems that there are some remaining dict in the config, although Spack seems to use ordereddict mostly everywhere.

Turns out that in Python 3.6+ dict implementation is ordered so everything works as expected.

I am looking into this to understand whether it is expected or not that dict are used.

Indeed, given that the new test I added (https://github.com/spack/spack/pull/14920/files) doesn't change behavior in your PR, I suspect this isn't doing what you want.

That might not have been what was intended back then but as far as I can tell bar-foo is what is expected both when using the config file order and when sorting.

If I modify the test so that the order is different, I can see that I don't get the expected behavior with Python 2.7 after my change.

@RemiLacroix-IDRIS Before you go any further, I'd recommend double-checking that retaining the original order actually updates the module names to what you expect from your original module name generation. It's possible that if the extensions are arbitrarily ordered there's nothing that can be done.

Before you go any further, I'd recommend double-checking that retaining the original order actually updates the module names to what you expect from your original module name generation. It's possible that if the extensions are arbitrarily ordered there's nothing that can be done.

It does match the original module name generation when using the config file order.

I am looking into this to understand whether it is expected or not that dict are used.

Turns out the problem was in the tests themselves! The configuration file was loaded differently in Spack and in the modules tests. Spack does use ordered dict everywhere, even with Python 2.7!

@sethrj I agree with posting a comment in #modules and merge this PR if no objection arise in 1-2 weeks. Can you post that message?

@RemiLacroix-IDRIS Do you have time to add a few more tests to check that the order of suffixes is the one we expect?

Do you have time to add a few more tests to check that the order of suffixes is the one we expect?

@alalazo What do you have in mind exactly? It's what I tried to do with 3362838.

@RemiLacroix-IDRIS For instance, if I understand this changeset correctly, maintaining the original configuration for the test we should have bar-foo as a suffix, right? I think we should check both and maybe other edge cases to verify the semantics are correct.

@alalazo I have extended the tests a bit.

OK, it's been a week with one positive and no negative feedback. The old (sorted) behavior is easy to do (just sort the keywords in your module file), so it should be easy for anyone to work around if they're surprised by the updated behavior. Merging!