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

Add failing test for #11763 #11841

Merged
merged 7 commits into from
Oct 7, 2022
Merged

Add failing test for #11763 #11841

merged 7 commits into from
Oct 7, 2022

Conversation

czoido
Copy link
Contributor

@czoido czoido commented Aug 11, 2022

Testing: #11763

@czoido czoido mentioned this pull request Aug 11, 2022
1 task
@memsharded memsharded added this to the 2.0.0-beta3 milestone Aug 11, 2022
@memsharded
Copy link
Member

Alternatives I can think of:

  • For lock create ., construct the graph from the test_package/conanfile.py, exactly the same as conan create does. This is a bit assymetric with respect to other "local" commands as conan graph, conan build, conan install that will take the package conanfile.py as root of the graph, not the test_package one. This approach will effectively lock the test_package "build_requires" in the lockfile, something that I have seen also requested and users struggling in 1.X
  • Capture the lockfile as it is doing now, without locking the test_package/conanfile.py and relax the "strict" attribute for the test_package/conanfile.py, so it doesn't fail when it cannot lock its tool_requires because they are not in the lockfile.

@memsharded
Copy link
Member

Update: The 1st approach has a challenge: to load the test_package/conanfile.py it is necessary to know the ref of the package. This is known at conan create time because it is exported first into the cache, and its reference is computed. Without exporting it, it becomes very complicated to obtain the reference. It might also have some other complexities, like locking the self version.

@memsharded
Copy link
Member

I have submitted a potential solution: make explicit the locking of test_package. Basically the line:

c.run("lock create test_package --lockfile=conan.lock --lockfile-out=conan.lock")

Note this is done after capturing the main lockfile, and it will append its tool_requires to the initial lockfile. The self.tested_reference_str is None in this case, the graph is not fully expanded, only the new requires declared by test_package/conanfile.py.

Wdyt?

@czoido
Copy link
Contributor Author

czoido commented Aug 22, 2022

I have submitted a potential solution: make explicit the locking of test_package. Basically the line:

c.run("lock create test_package --lockfile=conan.lock --lockfile-out=conan.lock")

Note this is done after capturing the main lockfile, and it will append its tool_requires to the initial lockfile. The self.tested_reference_str is None in this case, the graph is not fully expanded, only the new requires declared by test_package/conanfile.py.

Wdyt?

For me explicitly locking the test_package would be good enough 👍

@memsharded
Copy link
Member

The workaround explicitly locking test_package seems to be good atm.
We probably want to revisit this after #12046, moving this to beta.4

@memsharded memsharded modified the milestones: 2.0.0-beta3, 2.0.0-beta4 Sep 9, 2022
@memsharded memsharded self-assigned this Oct 7, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants