1. 08 Apr, 2009 1 commit
    • Keir Fraser's avatar
      tools: Always use sane upstream (`native') python paths · 535abca2
      Keir Fraser authored
      Previously, by default we would install our python modules into
      /usr/lib/python/xen, for example /usr/lib/python/xen/__init__.py.
      Upstream python's standard install location (a) includes the Python
      version number and (b) puts things in site-packages by default.
      Our best conjecture for the reason for this was an attempt to make the
      installs portable between different python versions.  However, that
      doesn't work because compiled python modules (.pyc), and C python
      extensions corresponding to one version of python, are not compatible
      across different versions of python.
      This is why upstream include the version number.
      site-packages is the standard location for locally-installed packages
      and is automatically included on the python search path.
      In this change, we abandon our own unusual python path setup:
       * Invoke setup.py in an entirely standard manner.  We pass
         PREFIX and DESTDIR using the appropriate options provided by
         setup.py for those purposes (adding them to setup.py calls
         which were previously lacking them).
       * Since the installation locations are now on the standard
         python path, we no longer need to add anything to the path
         in any of our python utilities.  Therefore remove all that
         code from every python script.  (Many of these scripts
         unconditionally added /usr/lib/python and /usr/lib64/python which
         is wrong even in the old world.)
       * There is no longer any special `Xen python path'.  xen-python-path
         is no longer needed.  It is no longer called by anything in our
         tree.  However since out-of-tree callers may still invoke it, we
         retain it.  It now prints a fixed string referring to a directory
         which does not to exist; callers (who use it to augment their
         python path) will thus add a nonexistent directory to their python
         path which is harmless.
       * Remove various workarounds including use of setup.py --home
         (which is intended for something completely different).
       * Remove tests for the XEN_PYTHON_NATIVE_INSTALL build-time
         environment variable.  The new behaviour is the behaviour which we
         should have had if this variable had been set.  That is, it is now
         as if this variable was always set but also bugs in the resulting
         install have been fixed.
      This should be a proper fix for the bug addressed by c/s 19515.
      Signed-off-by: default avatarIan Jackson <ian.jackson@eu.citrix.com>
  2. 25 Apr, 2005 1 commit
  3. 15 Apr, 2005 1 commit
    • katzj's avatar
      bitkeeper revision 1.1159.258.97 (42603992S3sF-t0yBth7NEBevozVOg) · fc56b123
      katzj authored
      [PATCH] Make non-native python path handling a
      > > Although I don't really agree with the installing of the
      > > python bits to the non-native paths, I can see where it's
      > > useful as long as the module ABI doesn't change if you're
      > > trying to distribute binary tarballs.  But with the current
      > > handling it adds module lookup costs for the native path case
      > > (which would be the norm) as well as prevents using
      > > PYTHONPATH to look to a different location for the modules.
      > >
      > > The attached patch changes things so that at first, the xen
      > > module is attempted to be imported from the stock paths.  If
      > > we get an ImportError exception, then it adds /usr/lib/python
      > > to the end of the python path and imports again.
      > Do you prefer this to just unconditionally addding /usr/lib/python to
      > the end of the path rather than the front?
      Slightly, but just because having /usr/lib/python in my sys.path is
      ugly :-)  I can look over it, though... patch doing that attached
      Signed-off-by: default avatarJeremy Katz <katzj@redhat.com>
      ===== tools/misc/netfix 1.13 vs edited =====
  4. 12 Jan, 2005 1 commit
  5. 02 Nov, 2004 1 commit
  6. 29 Jun, 2004 1 commit
  7. 25 Jun, 2004 1 commit
  8. 15 Jun, 2004 1 commit