Merge pull request #144 from embray/issue-3541

CHANGES.rst

@@ -4,7 +4,15 @@ astropy-helpers Changelog
 0.4.8 (unreleased)
 ------------------
 
-- Nothing changed yet.
+- Improved the ``ah_bootstrap`` script's ability to override existing
+  installations of astropy-helpers with new versions in the context of
+  installing multiple packages simultaneously within the same Python
+  interpreter (e.g. when one package has in its ``setup_requires`` another
+  package that uses a different version of astropy-helpers. [#144]
+
+- Added a workaround to an issue in matplotlib that can, in rare cases, lead
+  to a crash when installing packages that import matplotlib at build time.
+  [#144]
 
 
 0.4.7 (2015-02-17)

ah_bootstrap.py

@@ -56,6 +56,12 @@
     _text_type = str
     PY3 = True
 
+
+# What follows are several import statements meant to deal with install-time
+# issues with either missing or misbehaving pacakges (including making sure
+# setuptools itself is installed):
+
+
 # Some pre-setuptools checks to ensure that either distribute or setuptools >=
 # 0.7 is used (over pre-distribute setuptools) if it is available on the path;
 # otherwise the latest setuptools will be downloaded and bootstrapped with
@@ -84,15 +90,6 @@
     from ez_setup import use_setuptools
     use_setuptools()
 
-from distutils import log
-from distutils.debug import DEBUG
-
-# In case it didn't successfully import before the ez_setup checks
-import pkg_resources
-
-from setuptools import Distribution
-from setuptools.package_index import PackageIndex
-from setuptools.sandbox import run_setup
 
 # Note: The following import is required as a workaround to
 # https://github.com/astropy/astropy-helpers/issues/89; if we don't import this
@@ -104,6 +101,35 @@
 except ImportError:
     pass
 
+
+# matplotlib can cause problems if it is imported from within a call of
+# run_setup(), because in some circumstances it will try to write to the user's
+# home directory, resulting in a SandboxViolation.  See
+# https://github.com/matplotlib/matplotlib/pull/4165
+# Making sure matplotlib, if it is available, is imported early in the setup
+# process can mitigate this (note importing matplotlib.pyplot has the same
+# issue)
+try:
+    import matplotlib.pyplot
+except:
+    # Ignore if this fails for *any* reason*
+    pass
+
+
+# End compatibility imports...
+
+
+# In case it didn't successfully import before the ez_setup checks
+import pkg_resources
+
+from setuptools import Distribution
+from setuptools.package_index import PackageIndex
+from setuptools.sandbox import run_setup
+
+from distutils import log
+from distutils.debug import DEBUG
+
+
 # TODO: Maybe enable checking for a specific version of astropy_helpers?
 DIST_NAME = 'astropy-helpers'
 PACKAGE_NAME = 'astropy_helpers'
@@ -285,14 +311,46 @@ def use_astropy_helpers(path=None, download_if_needed=None, index_url=None,
             else:
                 raise _AHBootstrapSystemExit(e.args[0])
 
+
     if dist is not None:
-        # Otherwise we found a version of astropy-helpers so we're done
-        # Just activate the found distribibution on sys.path--if we did a
-        # download this usually happens automatically but do it again just to
-        # be sure
-        # Note: Adding the dist to the global working set also activates it by
-        # default
-        pkg_resources.working_set.add(dist)
+        # This is a bit hacky, but if astropy_helpers was loaded from a
+        # directory/submodule its Distribution object gets a "precedence" of
+        # "DEVELOP_DIST".  However, in other cases it gets a precedence of
+        # "EGG_DIST".  However, when activing the distribution it will only be
+        # placed early on sys.path if it is treated as an EGG_DIST, so always
+        # do that
+        dist = dist.clone(precedence=pkg_resources.EGG_DIST)
+
+        # Otherwise we found a version of astropy-helpers, so we're done
+        # Just active the found distribution on sys.path--if we did a
+        # download this usually happens automatically but it doesn't hurt to
+        # do it again
+        # Note: Adding the dist to the global working set also activates it
+        # (makes it importable on sys.path) by default.
+
+        # But first, remove any previously imported versions of
+        # astropy_helpers; this is necessary for nested installs where one
+        # package's installer is installing another package via
+        # setuptools.sandbox.run_set, as in the case of setup_requires
+        for key in list(sys.modules):
+            try:
+                if key == PACKAGE_NAME or key.startswith(PACKAGE_NAME + '.'):
+                    del sys.modules[key]
+            except AttributeError:
+                # Sometimes mysterious non-string things can turn up in
+                # sys.modules
+                continue
+
+        try:
+            pkg_resources.working_set.add(dist, replace=True)
+        except TypeError:
+            # Some (much) older versions of setuptools do not have the
+            # replace=True option here.  These versions are old enough that all
+            # bets may be off anyways, but it's easy enough to work around just
+            # in case...
+            if dist.key in pkg_resources.working_set.by_key:
+                del pkg_resources.working_set.by_key[dist.key]
+            pkg_resources.working_set.add(dist)
 
 
 def _do_download(version='', find_links=None, index_url=None):

astropy_helpers/__init__.py

@@ -4,3 +4,30 @@
 except ImportError:
     __version__ = ''
     __githash__ = ''
+
+
+# If we've made it as far as importing astropy_helpers, we don't need
+# ah_bootstrap in sys.modules anymore.  Getting rid of it is actually necessary
+# if the package we're installing has a setup_requires of another package that
+# uses astropy_helpers (and possibly a different version at that)
+# See https://github.com/astropy/astropy/issues/3541
+import sys
+if 'ah_bootstrap' in sys.modules:
+    del sys.modules['ah_bootstrap']
+
+
+# Note, this is repeated from ah_bootstrap.py, but is here too in case this
+# astropy-helpers was upgraded to from an older version that did not have this
+# check in its ah_bootstrap.
+# matplotlib can cause problems if it is imported from within a call of
+# run_setup(), because in some circumstances it will try to write to the user's
+# home directory, resulting in a SandboxViolation.  See
+# https://github.com/matplotlib/matplotlib/pull/4165
+# Making sure matplotlib, if it is available, is imported early in the setup
+# process can mitigate this (note importing matplotlib.pyplot has the same
+# issue)
+try:
+    import matplotlib.pyplot
+except:
+    # Ignore if this fails for *any* reason*
+    pass