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

Restore pre-3.28 behavior for which_package #5141

Merged
merged 8 commits into from
Jan 17, 2024

Conversation

mbargull
Copy link
Member

@mbargull mbargull commented Jan 16, 2024

Description

Fix linking check regressions by restoring pre-3.28 behavior for which_package.

Fixes gh-5136.

Checklist - did you ...

  • Add a file to the news directory (using the template) for the next release's release notes?
  • Add / update necessary tests?
  • Add / update outdated documentation?

@conda-bot conda-bot added the cla-signed [bot] added once the contributor has signed the CLA label Jan 16, 2024
Comment on lines 71 to 75
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
Copy link
Member Author

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.

Copy link
Contributor

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

conda_build/inspect_pkg.py Outdated Show resolved Hide resolved
"git",
"clone",
"https://github.com/conda/conda_build_test_recipe",
"--branch=1.21.11",
Copy link
Member Author

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.

Copy link
Contributor

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

Copy link
Member Author

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:

  1. Put out a build for a new 3.28 patch release once tagged upstream.
  2. Add this PR as a patch to the recipe for the current version to get a working downstream build.
  3. Mark all 3.28 builds as broken and thus continue to use 3.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.)

Copy link
Contributor

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

Comment on lines +28 to +31
# 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
Copy link
Member Author

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).

Copy link
Contributor

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

Copy link
Member Author

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 Show resolved Hide resolved
Comment on lines 215 to 222
# 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
Copy link
Member Author

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.

@mbargull mbargull marked this pull request as ready for review January 16, 2024 23:44
@mbargull
Copy link
Member Author

@kenodegard, I reviewed the code for which_package for <=3.27and found some more behavioral changes that3.28.x` introduced.
See the code as well as review comments in this PR for details.

I think we should revert the function's behavior to (mostly) what was done in <3.27 and put out a new 3.28 patch release for it.
We should discuss further changes (behavioral and/or performance-wise) for future versions rather than the 3.28.x line.

kenodegard
kenodegard previously approved these changes Jan 17, 2024
Copy link
Contributor

@kenodegard kenodegard left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

minor suggestions

tests/test_inspect_pkg.py Outdated Show resolved Hide resolved
tests/test_inspect_pkg.py Outdated Show resolved Hide resolved
news/5141-fix-which_package Outdated Show resolved Hide resolved
conda_build/inspect_pkg.py Outdated Show resolved Hide resolved
conda_build/inspect_pkg.py Outdated Show resolved Hide resolved
@kenodegard kenodegard requested a review from jezdez January 17, 2024 18:10
@kenodegard kenodegard mentioned this pull request Jan 17, 2024
67 tasks
Copy link
Contributor

@kenodegard kenodegard left a 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

@kenodegard kenodegard enabled auto-merge (squash) January 17, 2024 19:23
@kenodegard kenodegard removed this from the 24.1.x milestone Jan 17, 2024
@kenodegard kenodegard added this to the 3.28.0 milestone Jan 17, 2024
@kenodegard kenodegard merged commit d0daa2b into conda:3.28.x Jan 17, 2024
23 checks passed
@kenodegard kenodegard removed this from the 3.28.0 milestone Jan 18, 2024
@minrk
Copy link
Contributor

minrk commented Jan 18, 2024

Thanks for the fix!

@github-actions github-actions bot added the locked [bot] locked due to inactivity label Jan 18, 2025
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Jan 18, 2025
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
cla-signed [bot] added once the contributor has signed the CLA locked [bot] locked due to inactivity
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

Link checker cannot find dependencies for multi-output recipe in 3.28.3
4 participants