Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature/lockfiles partial #7763

Merged
merged 6 commits into from Sep 30, 2020

Conversation

memsharded
Copy link
Member

@memsharded memsharded commented Sep 28, 2020

Changelog: Fix: Removed check in lockfiles computed from other lockfile that it should be part of it. Users can check the resulting lockfile themselves if they want to.
Docs: conan-io/docs#1868

Fix #7739

jgsogo
jgsogo approved these changes Sep 30, 2020
Copy link
Contributor

@jgsogo jgsogo left a comment

I agree it is ok to relax the condition here. As long as the nodes that are present in both lockfiles are the same (same package-id) I think it is ok to build the new lockfile.

I can think about other development scenarios where this can be useful: two teams that develop different libraries that will be consumed by the same application, both teams want to share a master lockfile with all the dependencies to ensure they are using the same packages.

conans/test/functional/graph_lock/dynamic_test.py Outdated Show resolved Hide resolved
@memsharded memsharded merged commit f767fa1 into conan-io:develop Sep 30, 2020
2 checks passed
@memsharded memsharded deleted the feature/lockfiles_partial branch Sep 30, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[bug][question] Conan lockfile behavior change between conan 1.26 and conan 1.29.
3 participants