"Newly added dep is locked at a lower level" (also) reported when upgrade command is issued

[kivra-pauoli]

Pre-Check

• did a quick search in current issues first - found nothing related to this
• I am willing or interested in helping fix the issue

Environment

• using the latest rebar3

Current behaviour

Getting

===> Newly added dep ... is locked at a lower level. If you really want to unlock it, use 'rebar3 upgrade ...'

even if I upgrade (for the first time only).

This is probably because the analysis that leads to the message precedes the upgrade operation, but it's still kinda misleading.

Expected behaviour

No message when upgrade is issued.

[ferd]

Yeah, calling upgrade depends on the lock command. There is currently no way for rebar3 to silence this, as individual commands aren't aware of those that would follow them in the chain, unfortunately.

I'm not quite sure there's even a way to make this work without more drastically changing the rebar3 task model.

[kivra-pauoli]

We could "force" lock to know about upgrade, but I guess you're talking about implementing a more generic mechanism (?)

Is the whole chain pre-calculated or "on the go"?

In any case, I guess it would be strange for the "future" to affect the "past".

What about if lock had "options" and upgrade just called it with "hey, don't say anything for these and those dep.s"?

[ferd]

we can't "force lock to know about upgrade" right now, because the way it is invoked comes from higher up in the rebar3 abstraction mechanism (a top level handler gets the schedule from the task entered by the user, and it expands the dependency chain, then calls them one after the other by carrying state from one to the next). Any mechanism to teach lock to be taught about upgrade would likely need to be generic for all cases, including plugins.

Generally we'd advise people against making plugins or tasks that behave differently based on what follows them, because it messes with some forms of repeatability. Also, no arguments are ever passed from the demanded task to previous ones, which ends up implicitly getting users to store all relevant project preferences in rebar.config as a nice side-effect.

[kivra-pauoli]

Thanks for the detailed explanation. Closing as it doesn't seem this one has an easy solution, and it's mostly quality of life, not a huge improvement.