Conan: 'conan create' options

[db4]

I'm trying to create a package. If it does not have test_package folder, options in
conan create . user/channel -o option1=value1 -o option2=value2 ...
apply to the package itself. But if test_package is present, the same command line will try to set options for test_package, not the package itself! To work around this one should use
conan create . user/channel -o MyPackage:option1=value1 -o MyPackage:option2=value2 ...
I think this not very correct behaviour. Don't you?

[memsharded]

The correct approach for both cases is:

$ conan create . user/channel -o MyPackage:option1=value1 -o MyPackage:option2=value2

The explicit one. It should work the same in both cases, having or not a test_package folder.

The first one, using options without package scope still works for backwards compatibility and for some other cases (not conan create, but conan install) where the package name is still not defined. It shouldn't be used in general, and the docs shouldn't present it as such. So if you saw that in the docs, please tell where so we can fix it.

[db4]

Thanks for explanation. But why not to infer the package name for options if not explicitly specified? It's already inferred for reference (one can use user/channel instead of MyPackage/version@user/channel)

If not, I think conan create (and maybe others) should issue a warning when non-explicit option is supplied.

[memsharded]

The package name is actually inferred from the conanfile.py, and this is the source of confusion. When there is not test_package the conanfile.py is the root one, that has a name that can be used.

But when there is a test_package the conanfile used is test_package/conanfile.py, which doesn't have a name.

So:

$ conan create . user/testing -s option=value

is not a warning, it is the only way that you can supply options to test_package/conanfile.py. Same for conan install, conan build and other commands that are using a conanfile.py for consumption, and conanfile.py doesn't require to have a name attribute defined.

In any case I agree some extra logic could be added to issue a warning for those cases that could be differentiated.

[niosHD]

I just stumbled across the same issue with options when I tried to create a package as shared with -o shared=True.

Steps to reproduce:

1. Create template with test_package: conan new -t -s foo/0.1
2. Add the missing shared option by modifying the test_package/conanfile.py.
3. Build the package: conan create . bar/testing -o shared=True
4. Lookup what version has been built: conan search foo/0.1@bar/testing

For me this yields a package with shared=False. Without the test_package, on the other hand, everything works as expected and I get a package with shared=True. (e.g., conan new -s foo/0.1 && conan create . bar/testing -o shared=True && conan search foo/0.1@bar/testing)

Conan Version: 1.12.1