bugfix: work around ruamel.yaml vendoring issues (#9725)

- Delete references to ruamel.yaml at Spack start-up, if they are present

- ruamel.yaml generates a .pth file when installed via pip that has the
  effect of always preferring the version of this package installed at
  site scope (effectively preventing us from vendoring it).

- This mechanism triggers when implicitly importing the 'site' module
  when the python interpreter is started. In this PR we explicitly delete
  references to 'ruamel.yaml' and 'ruamel' in sys.modules, if any, after
  we set 'sys.path' to search from the directory where we store vendored
  packages. This ensures that the imports after those statements will be
  done from our vendored version.

- See #9206 for further details

1 files changed, 12 insertions, 0 deletions

diff --git a/bin/spack b/bin/spack
index c62871d6a6..171ee0f724 100755
--- a/bin/spack
+++ b/bin/spack
@@ -31,6 +31,18 @@ if sys.version_info[:2] == (2, 6):
 
 sys.path.insert(0, spack_external_libs)
 
+# Here we delete ruamel.yaml in case it has been already imported from site
+# (see #9206 for a broader description of the issue).
+#
+# Briefly: ruamel.yaml produces a .pth file when installed with pip that
+# makes the site installed package the preferred one, even tough sys.path
+# is modified to point to another version of ruamel.yaml.
+if 'ruamel.yaml' in sys.modules:
+    del sys.modules['ruamel.yaml']
+
+if 'ruamel' in sys.modules:
+    del sys.modules['ruamel']
+
 # Once we've set up the system path, run the spack main method
 import spack.main  # noqa
 sys.exit(spack.main.main())