[MacPorts] #50058: Executables installed by pip are not linked into macports path (and are not “select”able in any way).
#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
#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 Resolution: | Keywords: Port: pip | ------------------------+-------------------------------- Comment (by william@…): Apologies, submitted too soon, forgot to CC maintainer stromnov@macports.org, and can't see a way to do that after the event! Likewise I can't change the port field from the nonexistent `pip` to something which does exist, i.e. `py35-pip`! -- Ticket URL: <https://trac.macports.org/ticket/50058#comment:1> MacPorts <https://www.macports.org/> Ports system for OS X
#50058: Executables installed by pip are not linked into macports path (and are not “select”able in any way). --------------------------+------------------------ Reporter: william@… | Owner: stromnov@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: Port: py-pip | --------------------------+------------------------ Changes (by mf2k@…): * owner: macports-tickets@… => stromnov@… * version: 2.3.4 => * type: defect => enhancement * port: pip => py-pip -- Ticket URL: <https://trac.macports.org/ticket/50058#comment:2> MacPorts <https://www.macports.org/> Ports system for OS X
#50058: Executables installed by pip are not linked into macports path (and are not “select”able in any way). --------------------------+------------------------ Reporter: william@… | Owner: stromnov@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: Port: py-pip | --------------------------+------------------------ Comment (by stromnov@…): It's a rather bad practice to mix up several different package managers in one place (port and pip). If you, for example, manually install tornado using macports pip-3.5, then you can entirely break your macports installation due to dependency chain update (setuptools, certify and so on). So, it's preferably to install custom packages into separate dirs, or install custom packages using macports build system. -- Ticket URL: <https://trac.macports.org/ticket/50058#comment:3> MacPorts <https://www.macports.org/> Ports system for OS X
#50058: Executables installed by pip are not linked into macports path (and are not “select”able in any way). --------------------------+------------------------ Reporter: william@… | Owner: stromnov@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: Port: py-pip | --------------------------+------------------------ Comment (by william@…): Replying to [comment:3 stromnov@…]:
So, it's preferably to install custom packages into separate dirs, or install custom packages using macports build system.
I guess the “correct” response to the absence of a given package in macports is to request that it be added then (e.g. I might want there to exist a package py35-awscli (purely theoretically ;), in which case I should request that new port. It seems a pity not to be able to use the pip infrastructure in a more synergistic way with macports, but I guess we are where we are! This does ask the rather more serious question though: if it's bad practice to install packages in macports python using pip, why does macports provide a port of pip? That's a discussion for another day though! -- Ticket URL: <https://trac.macports.org/ticket/50058#comment:4> MacPorts <https://www.macports.org/> Ports system for OS X
#50058: Executables installed by pip are not linked into macports path (and are not “select”able in any way). --------------------------+------------------------ Reporter: william@… | Owner: stromnov@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: Port: py-pip | --------------------------+------------------------ Comment (by stromnov@…): The same situation exists in any other *nix-like OS: http://askubuntu.com/questions/431780/apt-get-install-vs-pip-install You can use pip to install custom packages in any other location than system-wide (using --user or --target options). -- Ticket URL: <https://trac.macports.org/ticket/50058#comment:5> MacPorts <https://www.macports.org/> Ports system for OS X
#50058: Executables installed by pip are not linked into macports path (and are not “select”able in any way). --------------------------+------------------------ Reporter: william@… | Owner: stromnov@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: Port: py-pip | --------------------------+------------------------ Comment (by hmijail@…): The "you can entirely break your macports installation" was scary, so I'd like to make sure that I got it right: One should NOT use pip to install packages on the macports directory tree (which is what a macports-installed pip would do by default!). The recommended procedure would be: * Install your python distribution and its pip (and probably its virtualenv) * Prepare a new place to install pip packages (like a virtualenv) * Use pip to install the packages into the new place A possible, but risky exception, would be: macports not carrying a pip- available package that has to be installed globally. It could then be installed into the macports directory tree, without fear of causing a conflict - until the day that macports *does* carry that package, and then the risk appears. Right? Is this documented somewhere? I'd say it should! -- Ticket URL: <https://trac.macports.org/ticket/50058#comment:6> MacPorts <https://www.macports.org/> Ports system for OS X
participants (1)
-
MacPorts