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

Fix a plugin (re-)ordering bug (re: #200). #206

Merged
merged 2 commits into from
Oct 12, 2022

Conversation

cnuahs
Copy link
Contributor

@cnuahs cnuahs commented Sep 1, 2022

This change fixes a bug introduced by commit 1988ab5 (re: #190)
that causes any changes to the default plugin order, imposed in
cic.run(), to be immediately reverted when handling adaptive
plugins/parameters (see cic.handleAdaptives()).

This change removes the call to c.order(), which reverts the plugin
order, in favour of using c.pluginOrder directly.

This change fixes a bug introduced by commit 1988ab5 (re: klabhub#190)
that causes any changes to the default plugin order, imposed in
cic.run(), to be immediately reverted when handling adaptive
plugins/parameters (see cic.handleAdaptives()).

This change removes the call to c.order(), which reverts the plugin
order, in favour of using c.pluginOrder directly.
@cnuahs
Copy link
Contributor Author

cnuahs commented Sep 1, 2022

@Nicroburst, can you confirm that this change fixes the behaviour you were observing?

@adammorrissirrommada
Copy link
Member

This fix is good, but I would advocate removing this behaviour of c.order(). It's too implicit, easy to accidentally and silently revert to default order, as was the case here.

Instead, some sort of argument that explicitly says "give me the default order please" would be good.

THis could have backwards compatibility issues for some scripts, possibly, though I doubt anyone uses c.order() with no args.

What do you think?

@cnuahs
Copy link
Contributor Author

cnuahs commented Sep 2, 2022

I agree. But maybe I'm the only one who is constantly tripped up by this c.order() business.

It would be more useful (I think) if c.order() (no args) returned the current plugin order, but made no changes... in effect {c.pluginOrder.name}, and you used c.order('default',true) to get the default order. c.order('plg1','plg2) would set the plugin order to the extent that the args define it.

There could be a separate argument to 'reset' the order to the default order, or maybe you just make two calls to c.order(), e.g., c.order(c.order('default',true))

Open question in my mind is whether c.order('plg1','plg2') should return the new order, or the old order (so you can restore it if desired). Is there any use case where that would be useful?

@adammorrissirrommada
Copy link
Member

If c.order('default',true) set the order to the default order, there would be no need for the slightly odd double-call above? I am fine with c.order() returning current order, even if it does seem that we are mixing a setter and getter into the one thing (as is currently the case anyway)

@adammorrissirrommada
Copy link
Member

You're definitely not the only one tripped up by the current form. That's how the bug was waved through in the first place, none of us saw it because the function's behaviour is impure and implicit.

@Nicroburst
Copy link
Collaborator

Yep, this fixes the behaviour I was seeing.

Copy link
Member

@bartkrekelberg bartkrekelberg left a comment

Choose a reason for hiding this comment

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

Looks good.

For clarity, could you rename the cic.order function and call it cic.setPluginOrder to emphasize that it changes the order (even with no input list it resets to the default order), and update the comments accordingly?

(Otherwise we may run into the same problem again down the line).

@bartkrekelberg bartkrekelberg merged commit fc07712 into klabhub:master Oct 12, 2022
@cnuahs cnuahs deleted the plugin-order-bug branch March 12, 2023 03:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants