I don't understand how pipx determines which CLIs are made available to install. For example, youtube-dl is, but ranger and googler are not. Is this a community-driven thing (if you want a particular package, add it to some index checked by pipx? Is it on the packages themselves i.e. youtube-dl has entry points structured in such a way that it is discoverable by pipx whereas ranger does not?
Which pipx subcommand are you referring to?
The pipx code checks the package information itself to discover binaries.
One thing that may be an issue is that after looking at it, the ranger code uses the scripts keyword inside of its setup.py, which may not be as reliable a method for pipx binary discovery. The more modern entry_points in setup.py to specify binaries has no problems AFAIK. Not only that, but complicating matters for pipx-app-discovery purposes, there is something happening in the ranger package around the function scripts_hack, which also might be complicating pipx's attempt to discover its binaries.
Upon looking at googler, it does not even appear to be a python package, which is necessary for pipx to work properly. There is no setup.py.
Which pipx subcommand are you referring to?
$ pipx install ranger
WARNING: You are using pip version 19.2.3, however version 19.3.1 is available.
No apps associated with package ranger.If you are attempting to install a library, pipx should not be used. Consider using pip or a similar tool instead.
Upon looking at googler, it does not even appear to be a python package, which is necessary for pipx to work properly. There is no
setup.py.
True, googler is a bit odd for a Python project; seems like everything is inside this one module that doesn't have a .py extension.
What do you hope to get out of installing ranger with pipx? The purpose of pipx is to install python-based applications (not libraries, hence the error message). Ranger is not an application: it doesn't have any command line entry points.
The error message could possibly be more explicit on this - "app" is an over-used term today. Something like
The
rangerpackage is not an application (i.e. it has no command-line entry points). Libraries likerangershould be installed with pip or a similar tool, or injected into an existing pipx application if appropriate.
What do you hope to get out of installing ranger with pipx? The purpose of pipx is to install python-based applications (not libraries, hence the error message). Ranger is not an application: it doesn't have any command line entry points.
Opened the issue bc I figured I might as well manage all the Python CLIs I use w/ pipx instead of Homebrew.
Ranger is not an application: it doesn't have any command line entry points.
Ranger isn't a library though, right? I've only used it as a CLI file manager; seems squarely in the wheelhouse of other CLI file managers like nnn and Midnight Commander.
Opened the issue bc I figured I might as well manage all the Python CLIs I use w/ pipx instead of Homebrew.
A great choice, and exactly what pipx is for!
Ranger isn't a library though, right? I've only used it as a CLI file manager; seems squarely in the wheelhouse of other CLI file managers like nnn and Midnight Commander.
I strongly suspect we are talking about different packages called ranger. Pipx (and I, earlier in this thread) only know about the python package ranger as listed on PyPI: https://pypi.org/project/ranger/ . If you look in the setup.py you'll see it doesn't have any entry points, and therefore is a library.
It looks like you are referring to an application listed on pypi as ranger-fm (https://pypi.org/project/ranger-fm/ ): looking in the setup.py, that installs a script called ranger. If you pipx install ranger-fm, you'll be sorted.
pipx in the past has had issues with the scripts in setup.py that ranger-fm uses (as opposed to entry_points. I'm wondering if that's why it's not working for the OP.
I think it's just that ranger isn't called ranger on PyPI - there's another entirely unrelated package called ranger, which coincidentally has no scripts/entry-points. pipx install ranger-fm works for me.
So in summary (for anyone viewing this Issue in the future)
setup.py in their repositoryentry_point or scripts in its package specification (most likely in setup.py)Edited to add "For pipx installation"
To be clear, python packages don't need a setup.py - there are a number of ways of specifying build metadata in a post-PEP517 world; in future we're likely to see more packages using a pyproject.toml, pursuant to PEP518. The important thing is whether the requested package A) exists on pypi and B) is an application rather than a library (i.e. has scripts or entry_points).
The googler issue is exactly the same as ranger - there exists a package called googler on PyPI but it's not the package OP was looking for. The googler listed on PyPI does not have any scripts/ entry points, and is therefore not an application.
Also, with --spec, the package doesn't need to be on pypi.
Is there a clear way to tell a user what is or is not a python package, other than "if it's on pypi, it is a package" ?
Ah I see PEP518 is still in the future. Does that mean that today, any python package has a setup.py?
It looks like you are referring to an application listed on pypi as
ranger-fm(https://pypi.org/project/ranger-fm/ ): looking in thesetup.py, that installs a script calledranger. If youpipx install ranger-fm, you'll be sorted.
I was, although much clearer if I included a link in the issue to begin with 馃檭
The
googlerissue is exactly the same asranger- there exists a package calledgoogleron PyPI but it's not the package OP was looking for. Thegooglerlisted on PyPI does not have any scripts/ entry points, and is therefore not an application.
This gets at my initial question i.e. how do packages become discoverable to pipx? So the first part of the answer is: PyPI.
Also, with --spec, the package doesn't need to be on pypi.
And the second is --spec.
Perhaps one intrinsic difficulty is that 99% of Python users (myself included) are 1) not in the business of producing libraries or packages and therefore 2) know comparatively less about matters of distribution (vs. dealing with pkgs/lib in the context of dependency management). That said, learning a lot on this thread :)
Would the project be interested in a small documentation PR on this i.e. 'how pipx finds packages?'
Also, I'm sated, happy to close issue if you like.
I've definitely been thinking about extra documentation based on this thread. I think the pipx maintainers will probably need to discuss what documentation we think is appropriate.
The bottom line is that pipx can install the same things that pip can install (i.e. python packages), if those packages have apps. pipx just has some extra features that make python packages with associated apps integrate well into your path, and install with their own isolated virtual environments.
So if you can pip install something and it has associated apps, you should be able to pipx install it.
Is there a clear way to tell a user what is or is not a python package, other than "if it's on pypi, it is a package" ?
Not if a package of the same name does exist on pypi.
Ah I see PEP518 is still in the future. Does that mean that today, any python package has a setup.py?
The future is now! Poetry, I believe flit, and maturin all produce setup.py-less python packages on PyPI. They just have different (better) ways of encoding the same metadata, primarily the pyproject.toml file (maturin uses Cargo.toml IIRC). There are still kinks being ironed out (primarily, pip supporting all the stuff it's meant to) but these are all in use.
Most helpful comment
I think it's just that
rangerisn't calledrangeron PyPI - there's another entirely unrelated package calledranger, which coincidentally has no scripts/entry-points.pipx install ranger-fmworks for me.