-
Notifications
You must be signed in to change notification settings - Fork 428
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
Restore pre-3.28
behavior for which_package
#5141
Conversation
672e8b9
to
7f39942
Compare
Signed-off-by: Marcel Bargull <[email protected]>
7f39942
to
6ed8ba1
Compare
Signed-off-by: Marcel Bargull <[email protected]>
Signed-off-by: Marcel Bargull <[email protected]>
Signed-off-by: Marcel Bargull <[email protected]>
Signed-off-by: Marcel Bargull <[email protected]>
2d2873d
to
0ef8203
Compare
conda_build/inspect_pkg.py
Outdated
try: | ||
lstat = (prefix / path).lstat() | ||
except FileNotFoundError: | ||
# FileNotFoundError: path doesn't exist | ||
return | ||
else: | ||
yield from _file_package_mapping(prefix).get(lstat, ()) | ||
|
||
path = Path(path).relative_to(prefix) | ||
except ValueError: | ||
# If path is already relative to prefix, we get a ValueError. | ||
pass |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know why this was changed to take paths not relative to the prefix in 3.28 .
To keep the change set small, I just added handling of non-relatives paths here instead of at which_packages
call sites.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah this change came about because I saw how before every call to which_package
we would strip the prefix, so inlining the relative logic here makes sense
"git", | ||
"clone", | ||
"https://github.com/conda/conda_build_test_recipe", | ||
"--branch=1.21.11", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is an unrelated change to make the tests pass.
It should probably not be picked verbatim for the main
branch.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
since we're about to start the January releases I'm thinking we will want to change the target branch and revert this change
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you mean this commit in particular or the whole PR?
I'm totally fine to drop the commit -- it was just a means to get "all green".
For the PR itself, I'd like us to have another 3.28
patch release if possible.
The thing is that we don't have any working 3.28
package on conda-forge (some are already marked broken
) and I'd like us to get one such release before we introduce further changes from the upcoming version.
Meaning, as a maintainer of infrastructure-related packages on conda-forge, I'd like to do one of the following:
- Put out a build for a new
3.28
patch release once tagged upstream. - Add this PR as a patch to the recipe for the current version to get a working downstream build.
- Mark all
3.28
builds asbroken
and thus continue to use3.27
for now on conda-forge.
Option 1 being the most preferred.
Option 2 is not ideal since we'd have divergent behavior up- and downstream.
Option 3 would be the last resort to get things working again.
(For conda-forge we'd rather want to increase not decrease the use of linking checks and omitting the linking checks via config would only create maintenance burden and is thus not an option I'm willing to go with.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
working with the team to figure out a release plan
added to 24.1.x milestone only because this is something that will need to be resolved and merged before the release can proceed
# Files might be deleted from the prefix during the build, but they should | ||
# still be recognized since they will be present in the run environment. | ||
(tmp_path / "deleted").unlink(missing_ok=True) # packageA | ||
(tmp_path / "deleted_shared").unlink(missing_ok=True) # packageA & packageB |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The linking checks are actually run on the host
prefix (an environment for actual run
dependencies is not created unless tests
are run).
The assumptions on the linking checks are actually about what would be provided via run
dependencies -- i.e., the checks on the host
prefix are not entirely accurate.
This conceptual issue is something to be discussed elsewhere.
But taking it as a status-quo leaves us with the issue that the previous 3.28 code seemed to more expect these checks to happen on an actual run
-dependency-resolved environment.
Since it is not the case, we'd rather have to work on the host
prefix' properties.
One such property is that a build script might remove files arbitrarily (e.g., one would link to $CC prog.c -o prog -l somelib ; rm libsomelib.so
and conda-build=3.27
would still detect the package that provides libsomelib.so
).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah I see, a mistake on my part in understanding where overlinking detection happened
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I wouldn't blame you for that :D.
The whole thing is probably under-documented, not the "most correct way", and also the code can be confusing since it has a host_prefix
-> run_prefix
renaming with the calls to check_overlinking_impl
...
tests/test_inspect_pkg.py
Outdated
# removed files should still return a package | ||
# this occurs when, e.g., a build script removes files installed by another package | ||
# (The opposite case with files really missing from the run environment, | ||
# e.g., due to a post-install script removing them, is less likely and not | ||
# covered.) | ||
# covered here.) | ||
for file in removed: | ||
assert not len(list(which_package(tmp_path / file, tmp_path))) | ||
assert len(list(which_package(tmp_path / file, tmp_path))) == 1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This change is a direct consequence of https://github.com/conda/conda-build/pull/5141/files#r1454205167 above, i.e., files may be removed during build from the host
prefix.
@kenodegard, I reviewed the code for I think we should revert the function's behavior to (mostly) what was done in |
Co-authored-by: Ken Odegard <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
minor suggestions
Co-authored-by: Ken Odegard <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added the regression test I wrote in #5140, otherwise LGTM
Thanks for the fix! |
Description
Fix linking check regressions by restoring pre-
3.28
behavior forwhich_package
.Fixes gh-5136.
Checklist - did you ...
news
directory (using the template) for the next release's release notes?Add / update outdated documentation?