-
Notifications
You must be signed in to change notification settings - Fork 434
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
include virtual packages in hash contents #4606
Conversation
For context, we need this as part of the work being done at conda-forge/conda-forge.github.io#1840, following approach documented at conda-forge/conda-forge.github.io#1839 |
cc @jezdez |
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.
LGTM; just small suggestions for extending the test a little bit.
- colorama # [win] | ||
- __win # [win] | ||
- appnope # [osx] | ||
- __osx # [osx] |
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.
- __osx # [osx] | |
- __osx # [osx] | |
- __linux # [ppc64le] |
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've gone with __linux # [linux]
. I don't think it's a good idea to use ppc64le
as the selector here as the selector and the virtual package differs.
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.
Yes, semantically the recipe doesn't makes sense. However, I changed it that way to let the test cover more cases, i.e., without it, we don't test whether the hash changes or not depending on if we have a virtual package dep on the same platform (OS) or not.
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 we have virtual architecture packages?
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.
Does the archspec virtual package count?
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.
Interesting. How would this be used? Maybe something like this?
- __osx # [osx] | |
- __osx # [osx] | |
- __archspec * ppc64le # [ppc64le] |
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.
Tried it locally and it works!
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.
Patched the test to cover for John's comment in this other suggestion. Would that work @mbargull?
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.
That's only true when archspec is not installed and is a fallback. Otherwise you get values like power9, power10 etc.
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.
Hm, it passes with or without archspec
in my dev env 🤷
tests/test-recipes/metadata/_noarch_with_no_platform_deps/meta.yaml
Outdated
Show resolved
Hide resolved
I've just updated the PR description with what had been written in the news file contained in this PR and I don't understand why this wasn't done initially when this was opened. It would help the review process, especially for the people relatively new to the code base like myself, compared to those that have plenty of experience working with it every day. To be clear, it adds stop energy to the review process if there is:
If this feature request is important for conda-forge, it must be filed as an issue in this repo, to be referenced during the code review, not the least for future code archeologists and consensus finding. I understand that filing issues has probably been dismissed as not helpful in the past, for various reasons (read: bad maintenance patterns), but I'd appreciate your help in making it easier for me and my colleagues to review your suggested changes. That would seriously help to unblock you as well I think. Thank you for your contributions -- as always -- @isuruf! |
What are the next steps here? |
One of the tests added in this PR is failing with a |
This seems to be lingering a bit. How can we help move this forward? |
I don't have the time to work on this PR. Anyone wants to take over? |
No worries. Should add that question wasn't directed at you specifically, but to this group as a whole. It's not obvious what still needs to be done to merge. For example there are outdated review comments above. Another review might clarify what's still needed. |
Hi @isuruf and @jakirkham ! Several conda-core dev team members are out of office currently but I'll bring this up early next week to see if we can get this moving (or at least get a timeline/update for you). Apologies for the delay! |
Thanks Bianca! 🙏 No worries. Things slip through the cracks sometimes. Just want to make sure that we pick this one back up if possible. |
I think @jezdez's comment still applies
So, someone should open an issue with a description. @mbargull added a good description for the top post here. We can copy that and add more context if needed. |
Done: #4861 |
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.
Thanks for elaborating in the ticket and providing the additional context, everyone!
4c9d5b3
to
97c2240
Compare
Co-authored-by: Marcel Bargull <mbargull@users.noreply.github.com>
Co-authored-by: Marcel Bargull <mbargull@users.noreply.github.com>
pre-commit.ci autofix |
for more information, see https://pre-commit.ci
Co-authored-by: jaimergp <jaimergp@users.noreply.github.com>
pre-commit.ci autofix |
for more information, see https://pre-commit.ci
@mbargull Any chance to re-review this? |
Thanks all! 🙏 |
Description
Noarch packages that use virtual packages have the virtual packages added to the hash contents of the package.
This facilitates the building of noarch packages multiple times for different platforms with platform specific dependencies.
If we build
noarch
packages with diverging run dependencies for different platforms, the hash in the build string stayed the same prior to this PR, i.e., the built variants got the exact same build strings and thus package file names didn't change.With this PR we can build different variants for, e.g.,
__linux
/__osx
/__win
, and get distinguished, non-clashing package file names.Resolves #4861.
Checklist - did you ...
news
directory (using the template) for the next release's release notes?Add / update outdated documentation?