-
Notifications
You must be signed in to change notification settings - Fork 202
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
Deprecate failure to resolve a template value #3285
base: develop
Are you sure you want to change the base?
Deprecate failure to resolve a template value #3285
Conversation
c508193
to
1b74197
Compare
Fleshed out some changes into #3287, there are still some logic issues that would need resolving:
|
@Flamefire conflict resolution and merge with develop please. |
1b74197
to
e46c69a
Compare
e46c69a
to
14e1664
Compare
bb6f129
to
edb4478
Compare
@akesandgren Done, so this is ready |
This one's too complicated for me, someone else that feels confident around that code needs to do the review. |
@Flamefire Can you do a sync with |
edb4478
to
b242525
Compare
Rebased. |
6996186
to
89e1d0b
Compare
@Flamefire Can this be re-targeted to the |
Sure can do. Do we want the deprecation there or the failure? For me the deprecation would be good to have "yesterday" and failure in 5.x |
That works for me, but only if we can ensure that not everyone who uses EasyBuild 4.9.0 will be exposed to deprecation warnings because we didn't do the necessary work to try and avoid them. For EasyBuild 5.0 we have an opportunity to make it a hard failure, so let's try doing that. |
I already did some work for that all over the place in this PR. As mentioned it would have been good to have the deprecation in yesterday such that we could have had time to find common remaining issues.
Might even need to deprecate it targetting 5.1 instead of 5.0 and/or allow this to pass via a switch. IIRC we have an option to allow e.g. deprecated toolchains which by default would error, don't we? We could use the same here for a version or 2. But the earlier we get this tested a lot the better. |
I found the option: |
3dfe8c1
to
902680b
Compare
902680b
to
5234cdb
Compare
3780590
to
b0f6191
Compare
PR for 5.x (with hard error): #4516 |
A failure in template resolving is currently hidden in the log although it is likely due to a bug in the code (either EasyBuild, EasyBlock or EasyConfig) This may lead to cryptic error messages later on or misbehave silently which is even worse. To not break builds completely deprecate continuing for now and promote to a hard error later.
If we only want the `len` of some list we don't need to resolve the templates. We cannot resolve templates in collect_exts_file_info like `installdir` present in e.g. `installcmd` of the extension options.
…ions & `asdict` Some dependencies may use templates referring to other dependencies which cannot yet be resolved. Hence add an opt-out to the enforcment of resolved templates via `expect_resolved=False` and use that. This allows use of `%(installdir)s` or `%(ext_name)s` and similar in the options.
…late Useful workaround if there are still some missing fixes.
Use the same templates in the compared EC and YEB files.
b0f6191
to
e29bf48
Compare
A failure in template resolving is currently hidden in the log although it is likely a bug in the code (either EasyBuild, EasyBlock or EasyConfig)
This may lead to cryptic error messages later on or misbehave silently which is even worse.
To not break builds completely deprecate continuing for now and promote to a hard error later. The message is now highly visible and existing cases can be fixed until the next release.
I did an extensive run during development of #3129 with this issue promoted to a hard failure and did not encounter a single instance. So I think there should be no issues with existing ECs (or very few)
@boegel To have enough time to check for existing issues until next release I recommend merging this soon.