[MacPorts] #50058: Executables installed by pip are not linked into macports path (and are not “select”able in any way).

[MacPorts]

#50058: Executables installed by pip are not linked into macports path (and are not
“select”able in any way).
-----------------------+--------------------------------
 Reporter:  william@…  |      Owner:  macports-tickets@…
     Type:  defect     |     Status:  new
 Priority:  Normal     |  Milestone:
Component:  ports      |    Version:  2.3.4
 Keywords:             |       Port:  pip
-----------------------+--------------------------------
 There's some prior discussion of this problem at
 https://github.com/pypa/pip/issues/113

 In short: when I install a python package using pip, its executables are
 installed into the appropriately versioned python tree, but those
 executables are not symlinked to somewhere which is on my PATH.

 In my example, I have installed macports' pip, and have `port select`ed
 `python35` and `pip35`. I then used pip to install the aws cli tools,
 `sudo pip install aws`. The `aws` binary is installed by `pip` at
 `/opt/local/Library/Frameworks/Python.framework/Versions/3.5/bin/aws`. So
 far so good. The problem is that that path is not on my `PATH` (of course
 … `port select` can't alter my path, only the individual symlinks in
 `/opt/local/bin` to the objects which are owned by that particular port
 for which `port select` was run).


 I would naively expect at first glance that issuing a `sudo port select
 pip pip35` would cause any binaries ''subsequently'' installed by that
 version of pip to be linked into my macports path `/opt/local/bin`. Of
 course that doean't happen with a standard `pip`. There follows the
 question of how to achieve this, since standard `pip` doesn't know it's
 supposed to do something about any binaries installed /after/ the `port
 select` operation, other than to install them in the appropriate place in
 the python heirarchy for the selected version of `pip`. This puts the
 question firmly in MacPorts' world, as per the latest comments on the
 github issue.

 Beporter's comment (third from last in that github issue at the time of
 writing) echos my feeling here … I would expect that something installed
 with the currently selected version of pip would end up on my path, though
 I completely understand why it doesn't at present.

 There's clearly some precedent for linking binaries to do with a specific
 python version directly in this way, since for example idle is linked thus
 on my installation, so the desired end result (I end up with a link
 `/opt/local/bin/aws ->
 /opt/local/Library/Frameworks/Python.framework/Versions/3.5/bin/aws`)
 would be consistent with this:

 {{{
 idle -> /opt/local/bin/idle3.5
 idle2.7 ->
 /opt/local/Library/Frameworks/Python.framework/Versions/2.7/bin/idle2.7
 idle3 -> /opt/local/bin/idle3.5
 idle3.4 ->
 /opt/local/Library/Frameworks/Python.framework/Versions/3.4/bin/idle3.4
 idle3.5 ->
 /opt/local/Library/Frameworks/Python.framework/Versions/3.5/bin/idle3.5
 }}}

 One way to achieve this (the “best” that I can think of so far) would be
 to modify MacPorts' `pip` so that when a given version of `pip` installs a
 binary it also links that into `/opt/local/bin`. This shouldn't be too
 hard to achieve but it's pretty invasive w.r.t. `pip`'s behaviour. It
 would, though, solve the oddness seen by me and others leading to
 `pip`-installed executables not appearing on my path. The `port select pip
 pipXX` command would also need on each invocation either to invoke `pip`
 or examine `pip`'s registry in order to unlink the executables which were
 installed by the version of `pip` being deselected, and link those owned
 by the version of `pip` being selected. Not rocket science, but a bit
 complicated.

 The alternative would seem to be to provide stub ports of some sort which
 use `pip` as the installation method under the hood but which handle the
 symlinking by providing `port select` machinery for each such port. That
 feels like a maintenance drag though (keeping up with `pip`'s repositories
 …)

 (Footnote: I can see that there's an existing port `py-awscli` which
 should provide what I need for now specifically in my example `aws` case,
 though it's pretty outdated, but that doesn't negate the general point
 about `pip` and paths in this bug …)

-- 
Ticket URL: <https://trac.macports.org/ticket/50058>
MacPorts <https://www.macports.org/>
Ports system for OS X