conan: Exporting same version does not change files in package dir

Hi, I am not sure if this has already been but I can’t find it anywhere. Example on one computer:

write some code
export foo/1.0@bar/foba
upload foo/1.0@bar/foba
conan install foo/1.0@bar/foba --build foo (only src, no binaries)
write some code
export foo/1.0@bar/foba
upload foo/1.0@bar/foba
conan install foo/1.0@bar/foba -u

The package files do not change calling the second time conan install <..> -u. In addition it should complain as the new package has to be compiled. Deleting the directory .conan/data/foo and installing the package works. Maybe a hash could be stored in the package and in the export directory. If they don’t match it could be detected that they are out of sync. I think that atm conan only checks if the remotes and the export directory are synced (and they are so conan does not detect the change), but if the package is exported and used on the same machine, the package dir never gets updated.

Maybe I am doing something wrong, the conan file I used for this test: https://github.com/lms-org/lms/blob/develop/conanfile.py

About this issue

Original URL
State: closed
Created 8 years ago
Comments: 18 (11 by maintainers)

Most upvoted comments

Ok, I think now I understood the issue.

The underlying design decision was made because we realized that sometimes, a package was built, but there was something missing in the package_info that doesnt require a full package rebuild (imagine boost, long times), so it is enough to change the recipe and export the recipe and it works. We let the package creators be responsible for that, and let them conan remove the binaries if they wanted to regenerate it.

Certainly, some information about the package binaries could help. Will have a look, thanks for your feedback!

memsharded on Sep 30, 2016

No, it is not rebuilt. The flow is as follows:

Starting with the installed reference (MyPackage/0.1@user/channel) or conanfile, the dependency tree is evaluated and built incrementally. For that purpose, it is necessary to retrieve the dependencies recipes (the conanfile.py of the dependencies, not the binaries).
For each node in the dependency tree, starting upstream (the packages that do not depend on anyone else, it is check for existence of a binary for that dependency that matches the current settings.
If such a binary is found in the local cache, it is used
If the -update argument is used, such local binary will be checked against the remote one, and if there is a remote binary newer than the local one, it will be retrieved and replace the old one. Note that this only happens when the same package reference MyPackage/0.1@user/channel is used, i.e., it does not upgrade to 0.2 or newer versions of the library, but only for newer builds of the same package.
If there is no binary, and --build=missing, then it will build locally the package from sources

The remotes are search in order as defined in the remote list ($ conan remote list), or in the remote explicitly specified. If a package was retrieved from one remote, --update updates will look that specific remote by default, unless remote explicitly especified.

If we used --build or --build=MyPackage then it will always build from sources, it will not try to retrieve binaries from the remotes.

memsharded on Sep 29, 2016