conan-io / conan-io/docs

Wildcard use in reference patterns is unclear

Open
#812 2 comments 0 reactions 0 assignees View on GitHub
complex: medium component: bintray priority: medium stage: queue type: look into
Dominant language
C++
Stars
125
Forks
382
Avg merge
22h 39m
Merged PRs (30d)
21

Description

These basic search patterns, which are stated in the documenation, do work:
```
$ conan search -r sbre-public '*'
Existing package recipes:

boost/1.64.0@sbre/nightly
boost/1.64.0@sbre/testing
libalmath/0.1@sbre/nightly
libalmath/0.1@sbre/testing
libqi/1.5.0@sbre/nightly
libqi/1.5.0@sbre/testing
pthreads-win32/2.9.1@sbre/nightly
pthreads-win32/2.9.1@sbre/testing
qiframework/0.1@sbre/nightly
qiframework/0.1@sbre/testing
qilang/0.1@sbre/nightly
qilang/0.1@sbre/testing
sbretoolchain/2.9.0@sbre/nightly
sbretoolchain/2.9.0@sbre/testing

$ conan search -r sbre-public 'boost/*'
Existing package recipes:

boost/1.64.0@sbre/nightly
boost/1.64.0@sbre/testing
```

Now let's try to search by version:

```
$ conan search -r sbre-public '*2.9.1*'
There are no packages matching the '*2.9.1*' pattern

$ conan search -r sbre-public '*2.9.1/*'
There are no packages matching the '*2.9.1/*' pattern

$ conan search -r sbre-public '*/2.9.1'
Existing package recipes:

pthreads-win32/2.9.1@sbre/nightly
pthreads-win32/2.9.1@sbre/testing

$ conan search -r sbre-public '*/2.9.1/*'
Existing package recipes:

pthreads-win32/2.9.1@sbre/nightly
pthreads-win32/2.9.1@sbre/testing

$ conan search -r sbre-public '*/2.9.1@*/*'
Existing package recipes:

pthreads-win32/2.9.1@sbre/nightly
pthreads-win32/2.9.1@sbre/testing
```

Oddly enough, these patterns do work:
- `*/2.9.1` which is a pattern that doesn't try to match user/channel
- `*/2.9.1/*` which looks wrong (missing `@username`)

`*/2.9.1@*/*` looks well-formed, and works as expected.

Now let's try to search by user name:

Those patterns work:
`*/*@sbre*`
`*/*@sbre/*`

But those don't:
`*@sbre*`
`*@sbre/*`

And `*sbre*` alone will only search on the package name, not on the user name.
```
$ conan search -r sbre-public '*sbre*'
Existing package recipes:

sbretoolchain/2.9.0@sbre/nightly
sbretoolchain/2.9.0@sbre/testing
```

Now here's my main issue: matching by channel
```
$ conan search -r sbre-public '*/nightly'
There are no packages matching the '*/nightly' pattern

$ conan search -r sbre-public '*sbre/nightly'
There are no packages matching the '*sbre/nightly' pattern

$ conan search -r sbre-public '*@sbre/nightly'
There are no packages matching the '*@sbre/nightly' pattern

$ conan search -r sbre-public '*0.1@sbre/nightly'
There are no packages matching the '*0.1@sbre/nightly' pattern

$ conan search -r sbre-public '*@sbre/nightly'
There are no packages matching the '*@sbre/nightly' pattern

$ conan search -r sbre-public '*/0.1@sbre/nightly'
Existing package recipes:

libalmath/0.1@sbre/nightly
qiframework/0.1@sbre/nightly
qilang/0.1@sbre/nightly

$ conan search -r sbre-public '*/*@sbre/nightly'
Existing package recipes:

boost/1.64.0@sbre/nightly
libalmath/0.1@sbre/nightly
libqi/1.5.0@sbre/nightly
pthreads-win32/2.9.1@sbre/nightly
qiframework/0.1@sbre/nightly
qilang/0.1@sbre/nightly
sbretoolchain/2.9.0@sbre/nightly

$ conan search -r sbre-public '*/*/nightly'
There are no packages matching the '*/*/nightly' pattern

$ conan search -r sbre-public '*/*@*/nightly'
Existing package recipes:

boost/1.64.0@sbre/nightly
libalmath/0.1@sbre/nightly
libqi/1.5.0@sbre/nightly
pthreads-win32/2.9.1@sbre/nightly
qiframework/0.1@sbre/nightly
qilang/0.1@sbre/nightly
sbretoolchain/2.9.0@sbre/nightly
```

This is all confusing, so matching syntax should be better documented (unless I overlooked something), but the syntax could be improved (even only for Conan 2.0). I don't understand for example why sometimes`*` can be greedy (as in `boost/*`), and other times not (as in `*/nightly`), and why it sometimes only matches the package name, and other times not.

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.