Installation Issue : Dangling symlink six and decorator

[Himanshu Mishra]

This might be a user specific bug but this is what happened with me.

I installed `python-scipy` using apt-get on ubuntu. While using `scikit-image` I had to import the module `scipy.lib.six` and then I got `No module named six`. But I had already installed `six`. So, I did some lookups and came to know that while installing, scipy creates a symlink to the `six` module inside `scipy.lib`. And that's how `scipy.lib.six` import works. But there's a catch. The symlink is created as _`../../six.py`_.

Here the issue can get user-specific. For me, six was installed inside `/usr/local/lib/python-2.7/dist-packages/` and scipy inside `/usr/lib/python-2.7/dist-packages/`. Note the `/local`. So, scipy was not able to find any `../../six.py`, that's what the issue is about. Same goes for `scipy.lib.decorator`.

If this is considered as a bug, possible solutions which I can think of is :

1. **Complete module import inside `scipy.lib.six`**

  Having a wildcard import of the six module.
  We can also have a try/catch block to raise a custom exception.

2. **Create a symlink after locating the module**

  ```python
  In [1]: import six

  In [2]: six.__file__
  Out[2]: '/usr/local/lib/python2.7/dist-packages/six.pyc'
  ```

**Same goes for `decorator`.**

[Julian Taylor (jtaylor)]

scipy depends on python-six and python-decorator so it should have also been present in /usr/lib/python-2.7/dist-packages/ and found.
Are these files present on your system?

I cannot reproduce the issue even when I put a six into /usr/local

note newer versions of the scipy package only symlink decorator, six is now an embedded copy as it contains some patches.

[Peter Tripp (notpeter)]

As far as I'm concerned this is a packaging bug plain and simple. There's no reason to have the python-scipy package depend upon python-decorator/python3-decorator with a fragile symlink.

Upstream scipy 0.17.0 does not symlink decorator.py it vendors a working copy:
https://github.com/scipy/scipy/blob/v0.17.0/scipy/_lib/decorator.py

jtaylor switched to a symlink ages ago (2013-05-09) in debian upstream python-scipy 0.12.0-1
https://launchpad.net/debian/+source/python-scipy/0.12.0-1

I understand the logic behind that change and while there's nothing in the Debian Python Packaging guide which explicitly forbids it, making a symlink to a file provided by another package strikes me as extremely poor form. Personally I'd vote for re-including the copy decorator.py included upstream. Alternatively a simple "from decorator import *" in decorator.py would be similarly as kludgy but without a guaranteed broken scipy when pip uninstalls the system decorator.

Thoughts jtaylor?

----

Steps to reproduce:

pip install a package which has a dependency on any version of decorator newer than the 4.0.6 provided by python-decorator. Pip will happily uninstall it from the old location (/usr/lib/python3/dist-packages) and install the newer version in an alternate location (/usr/local/lib/python3.5/dist-packages/ for me) which breaks the symlink.

For googlability when running import scipy._lib.decorator the error is:
ImportError: No module named 'scipy._lib.decorator'

[Matthias Klose (doko)]

> when pip uninstalls the system decorator

yes, that's the issue here. pip should not touch files which it doesn't handle. Is this still not fixed?

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Kai Kasurinen (kai-kasurinen)]

Fixed in version python-pip/1.5.6-4

python-pip (1.5.6-4) unstable; urgency=medium
...
 * Add patch (reviewed by upstream, but not commited there yet) to prevent
     pip from removing system python packages (Closes: #771794)