Steps to reproduce the issue
I encountered a very non-helpful error message when trying to concretize gromacs with a value for the variant openmp_max_threads.
E.g., running
$ spack spec -lI gromacs openmp_max_threads=none
==> Error: '<' not supported between instances of 'str' and 'bool'
Similarly,
$ spack spec -lI gromacs openmp_max_threads=64
==> Error: '<' not supported between instances of 'str' and 'bool'
When run with the --debug flag, (see output file in Additional Information section), I see that the error is in the execution of "sorted(self.variant_values_from_specs)" in the file lib/spack/spack/solver/asp.py.
I get the same results when attempting to concretize an environment with gromacs as a root spec and a requires setting the openmp_max_threads for gromacs (in which case the error message is particularly less than helpful, as the error message (even with debug flag) does not specify which of the ~100 root specs is the cause of the problem, much less which variant, etc). I had to add debugging code to determine the issue was related to package variants, much less which package).
I believe there are two issues here:
-
gromacs appears to have an issue with the openmp_max_threads flag. I have looked at the recipe, and I am quite confused at what the recipe is trying to do:
1a) the value is used to set the CMake flag GMX_OPENMP_MAX_THREADS which seems to want a string representation of an integer.
1b) the default value of "none" seems to also suggest a string type
1c) There is a conflicts line (around line 182) with "+openmp_max_threads", i.e. treating the variant as a boolean
-
in my opinion, the main spack code should be more robust in handling such issues from package recipes. I have not so far been able to reproduce the TypeError exception with another package/variant, so it seems like this issue is due to something funky with the gromacs package. But it does seem to be at least theoretically plausible that another current or future package recipe could similarly tickle a TypeError in this way, and so spack should produce better diagnostics in this case. I others agree, I will open an issue in the spack repo.
Error message
Error message
==> Error: '<' not supported between instances of 'str' and 'bool'
Information on your system
$ spack debug report
* **Spack:** 1.2.0.dev0
* **Builtin repo:** https://github.com/spack/spack-packages/commit/119680aeee8ea802c6111b7167583bddef97e82f
* **Python:** 3.6.8
* **Platform:** linux-rhel8-zen2
Additional information
Maintainers of gromacs: @eirrgang @junghans @mabraham
As it is a concretization error, there are no spack-build-*.txt files
General information
Steps to reproduce the issue
I encountered a very non-helpful error message when trying to concretize gromacs with a value for the variant openmp_max_threads.
E.g., running
Similarly,
When run with the --debug flag, (see output file in Additional Information section), I see that the error is in the execution of "sorted(self.variant_values_from_specs)" in the file lib/spack/spack/solver/asp.py.
I get the same results when attempting to concretize an environment with gromacs as a root spec and a requires setting the openmp_max_threads for gromacs (in which case the error message is particularly less than helpful, as the error message (even with debug flag) does not specify which of the ~100 root specs is the cause of the problem, much less which variant, etc). I had to add debugging code to determine the issue was related to package variants, much less which package).
I believe there are two issues here:
gromacs appears to have an issue with the openmp_max_threads flag. I have looked at the recipe, and I am quite confused at what the recipe is trying to do:
1a) the value is used to set the CMake flag GMX_OPENMP_MAX_THREADS which seems to want a string representation of an integer.
1b) the default value of "none" seems to also suggest a string type
1c) There is a conflicts line (around line 182) with "+openmp_max_threads", i.e. treating the variant as a boolean
in my opinion, the main spack code should be more robust in handling such issues from package recipes. I have not so far been able to reproduce the TypeError exception with another package/variant, so it seems like this issue is due to something funky with the gromacs package. But it does seem to be at least theoretically plausible that another current or future package recipe could similarly tickle a TypeError in this way, and so spack should produce better diagnostics in this case. I others agree, I will open an issue in the spack repo.
Error message
Error message
Information on your system
Additional information
Maintainers of gromacs: @eirrgang @junghans @mabraham
As it is a concretization error, there are no spack-build-*.txt files
General information
spack debug reportand reported the version of Spack/Python/Platformspack maintainers <name-of-the-package>and @mentioned any maintainers