Conan: How do I replicate `conan test_package` with discrete commands?

[cleeland]

I would like to replicate the steps that test_package command takes without actually building a test package. However, I cannot seem to find all the correct steps in order to get this to work.

If this is already documented somewhere, my apologies in advance. I've just not found it yet.

[memsharded]

The closest explanation would be in: http://docs.conan.io/en/latest/packaging/getting_started.html#creating-and-testing-packages

Not the real step by step instructions, those would be (for just one configuration, repeat with a different build folder for each configuration):

$ conan export user/channel
$ cd test_package
$ mkdir build && cd build
$ conan install ..  --build=PkgName # we are installing test_package, which will require the exported package recipe
$ conan build  # this is building the test_package/conanfile -> build()
$ /bin/example  #or whatever is executed inside test_package/conanfile.py->test()

The conan install will use the profile, settings, etc. passed to conan test_package

Do you think that it would be useful to add the detailed steps to the docs? Thanks!

[cleeland]

Do you think that it would be useful to add the detailed steps to the docs? Thanks!

YES! Many people understand things better when they see how things are done. That's why we read source code rather than documentation :)

[cleeland]

Isn't there a conan source step?

[cleeland]

So, test_package builds my package as a side-effect of requiring (having a dependency upon) my package. What if I want to build my package directly rather than via a side-effect? What would the steps be in that case?

[memsharded]

The source() step of the recipe is executed inside the local cache, when the package is installed.

Yes, the test_package builds the package as default, but that could be easily skipped with:

$ conan test_package --build=missing

If you want to build it directly, then test, you could fire the build yourself, then test_package without building (provide same settings/profile to both commands if using different than the default):

$ conan install Pkg/0.1@user/channel --build=Pkg 
$ conan test_package --build=missing

[cleeland]

I'm trying to not use test_package at all. It seems strange to me to build a package as a side-effect rather than explicitly.

What I initially tried is to do something like this:

$ mkdir newpkg
$ cd newpkg
$ conan new newpkg/0.1@foo/testing
$ vi conanfile.py
...define source, build, package as well as attributes...
$ conan source
$ conan build
$ conan package

but that didn't work. I finally found that I needed to do conan export before conan source, but it still didn't work.

What I'm understanding is that the source only ever happens in the cache; if that's the case, then why is there even a conan source command? I can execute it, but I can't do anything useful with what it gives me.

[memsharded]

conan test_package is just the natural evolution of what you are describing. Originally the workflow for creating packages was:

$ conan new Pkg/0.1@user/channel
# customize recipe
$ conan export user/channel
$ conan install Pkg/0.1@user/channel --build=Pkg
# cd .. && mkdir consumer && cd consumer
# write a conanfile.txt/py, a CMakeLists.txt and example.cpp
$ conan install .
$ cmake -G "..."
$ make #or cmake --build . --config Release
$ bin/example #or run whatever to check

conan test_package does nothing but wrap and automate it. We have found that it is incredibly useful, systematic and help catching 99% of packaging errors, and that is why we present it as the default way to create and test packages.

What you are trying to use is the local workflow with the local commands. That is not the default way to create packages, but a way to allow an easier way to debug and develop code. Even if that process can conclude with a package_files command, the recommended way to really create the package to ensure reproducibility is via direct conan install or indirect conan test_package. The conan source command also works locally. In my explanation above, I didn't say so, because no conan source command is involved in that process. The call to source() method is already called by the install when working in the local cache. The local commands use case is mostly when you have to develop code from several different packages that are related to each other at the same time. So you can run incremental builds and package from user space rather than from the local cache. It will probably be evolving: https://github.com/conan-io/conan/issues/1377

[cleeland]

This helps. It helps to know the history because that history motivates the test_package. If there is not a tutorial that already describes this, I would suggest one.

IMHO, I think the workflow might benefit from further refinement. While I now understand the "why" for test_package, it still feels weird that my package gets built/installed as a side-effect of wanting to use the package. For me, the test_package violates the so-called "principal of least surprise". As a longtime C++ developer, the workflow of write-buildthing-buildtest-run-repeat is more natural than write-buildtest-repeat

I'm not sure what "further refinement" means right now. Hopefully as I continue to work with conan in my environment and ask dumb questions that garner smart answers, the meaning will become more clear.

[danimtb]

I think the initial question was addressed and even before conan 1.0 there is a conan test command. Closing this, please reopen if there are further questions!