Bad initial user experience with searching

ArekPiekarz commented 6 years ago

Summary:

Searching for all or specific packages as a new user is impossible or harder than in other package managers.

Scenario 1:

Try to list all available packages.

$ conan search
There are no packages

Result in Pacman package manager in Msys2 (with Pacboy wrapper):

$ pacboy find
mingw32/mingw-w64-i686-3proxy 0.8.9-1
    3proxy - tiny free proxy server (mingw-w64)
mingw32/mingw-w64-i686-4th 3.62.5-1
    A Forth Compiler (mingw-w64)
(...long list cut by me...)
msys/zsh 5.4.2-1
    A very advanced and programmable command interpreter (shell) for UNIX
msys/zsh-doc 5.4.2-1
    Info, HTML and PDF format of the ZSH documentation

Scenario 2:

Try to find Boost package:

$ conan search boost*
There are no packages

Result in Pacman package manager in Msys2:

$ pacboy find boost*
mingw32/mingw-w64-i686-boost 1.66.0-1
    Free peer-reviewed portable C++ source libraries (mingw-w64)
mingw64/mingw-w64-x86_64-boost 1.66.0-1 [installed]
    Free peer-reviewed portable C++ source libraries (mingw-w64)

Scenario 3:

Assuming a user learned that conan search by default checks only local packages and about existence of remotes, try to find Boost package on any of them:

$ conan search -r "*" boost*
usage: conan search [-h] [--case-sensitive] [-r REMOTE] [--raw]
                    [--table TABLE] [-q QUERY] [-o]
                    [pattern]
conan search: error: unrecognized arguments: .bash_profile .bashrc .config .dbus-keyrings .git-prompt.sh .gitconfig .inputrc .lesshst .local .minttyrc .profile .vim .viminfo .vimrc boost*
ERROR: Exiting with code: 2

Scenario 4:

Assuming the user learned there is no pattern matching for remotes and what remotes are available with conan remote list, try to list all packages on one remote.

$ conan search -r conan-center "*"
usage: conan search [-h] [--case-sensitive] [-r REMOTE] [--raw]
                    [--table TABLE] [-q QUERY] [-o]
                    [pattern]
conan search: error: unrecognized arguments: .bash_logout .bash_profile .bashrc .config .dbus-keyrings .git-prompt.sh .gitconfig .inputrc .lesshst .local .minttyrc .profile .vim .viminfo .vimrc
ERROR: Exiting with code: 2

Scenario 5:

Assuming the user learned it's not possible to list all packages on a remote, try to find Boost ones on each of remotes:

$ conan search -r conan-center boost*
There are no packages matching the boost* pattern

$ conan search -r conan-transit boost*
Existing package recipes:

boost/1.61.0@lasote/vcpkg
boost/1.62.0@lasote/vcpkg
boost/1.64.0@hoxnox/testing
boost/1.64.0@orhun/testing
boost/1.64.0.b2@orhun/testing
boost/1.64-4.0@laohyx/vcpkg
boost-di/1.0.1@lasote/vcpkg
boost-process/0.5.0@eliaskousk/stable
boost-sml/git-master@erikzenker/testing
boost.simd/4.17.3.0@orhun/testing

At last some success, although for beginners it may seem confusing why some packages are duplicated. Also only older Boost versions are available.

Scenario 6:

Try to find the newest Boost 1.66 package. The user already knows it's not in conan-center nor conan-transit. Assuming he learned about Bincrafters remote and how to add it:

$ conan remote add bincrafters https://api.bintray.com/conan/bincrafters/public-conan

$ conan search -r bincrafters boost*/1.66*
Existing package recipes:

boost_accumulators/1.66.0@bincrafters/testing
boost_algorithm/1.66.0@bincrafters/testing
boost_align/1.66.0@bincrafters/testing
(...long list cut by me...)
boost_winapi/1.66.0@bincrafters/testing
boost_xpressive/1.66.0@bincrafters/testing

Finally we found the library we wanted in the newest version, after stepping through many hoops. Could this process be made easier for newcomers?

Environment:

Conan 1.0.1 from pip3 from Msys2 Windows 10 x64

[x] I've read the CONTRIBUTING guide.
[x] I've specified the Conan version, operating system version and any tool that can be relevant.
[x] I've explained the steps to reproduce the error or the motivation/use case of the question/suggestion.

lasote commented 6 years ago

Thanks for your feedback.

About the first 2 scenarios, maybe we could show "There are no packages in the local cache, use -r to search in a remote" to help user understand.
About the 3/4. It should work, actually in native windows, mac, linux works, I have to check in msys2. The problem is normally to pass the star without quotes "*", the shell expand the star to the current files (afaik we can't do anything with that) but in your example there are quotes, so we should investigate to understand it.
About 5/6 we are starting to populate conan-center with packages, we have many inclusion requests pending and finally, some time to spend in the public repository. We will work close with bincrafters community and we will increase the awareness of the bincrafters community also.

Thanks again for such detailed report.

memsharded commented 6 years ago

Yes, I agree that the "remotes" could be a bit more evident. Right now if you type:

$ conan search --help

The paragraph will explain that, but the --remote argument could be better explained.

liberforce commented 6 years ago

I've been bitten by this one too. I also agree that as a newcommer, having the search returning nothing is surprising. I'm new to conan and saw in the help that there was a change in the repository layout, and first thought that may be the source of the problem. Luckily I read the search command help and found, hidden in the middle of the whole paragraph, that local search was the default.

I think that defeats the purpose of a package manager. When I'm searching for something, it's because I don't know where it is. So I propose this:

Change the help paragraph of the search command so that it immediately tells the default comportment of the command.

For the current comportment, this would be:

Searches package recipes and binaries in the local cache (by default) or in a remote.

This would make the following sentence unnecessary:

You can search in a remote or in the local cache, if nothing is specified, the local conan cache is assumed.

change the default comportment to search by default in all available remotes
add a --local option to search locally explicitly
allow to specify a remote on the command line to restrict search to this remote (the way it does currently)
alllow use of multiple remotes on the command line if I want to restrict my search to a subset of all the configured remotes

If you see no fit for changes 2-5, then at the very least, allow a way to search on all remotes like -r all or something similar.

memsharded commented 6 years ago

I agree that the paragraph (point 1) can be improved. Please contribute it directly if you feel.

Regarding the other points 2-5, sorry, but it is not possible. This would be breaking behavior, and we can't do this, at least until 2.0, and that is very far away.

Regarding -r=all, yes, this is already merged, it will be available in conan 1.1: https://github.com/conan-io/conan/pull/2348

liberforce commented 6 years ago

Maybe this could get a 2.0 milestone if the only problem is the change of default behavior?

liberforce commented 6 years ago

Chocolatey for example uses the --local-only option for local searches. This would be the counterpart to -r=all, as searching on all remotes (+ local?) would become the default behavior.

memsharded commented 2 years ago

conan search has already been changed in 2.0-alpha to search for packages in all configured remotes by default, not in local cache. And in all remotes, even without specifying it, so I think this can be closed now as implemented.

conan-io / conan