-
Notifications
You must be signed in to change notification settings - Fork 192
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
CLI: verdi profile setdefault to set-default #6426
CLI: verdi profile setdefault to set-default #6426
Conversation
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 @agoscinski some minor requests
message_ = message | ||
if version is not None: | ||
message_ = f'{message_} (this will be removed in v{version})' |
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.
Why the temporary reassignment, wouldn't the following be identical?
message_ = message | |
if version is not None: | |
message_ = f'{message_} (this will be removed in v{version})' | |
if version is not None: | |
message = f'{message} (this will be removed in v{version})' |
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.
This will fail. As soon as we want to assign message
it is assumed to be local
, so the message
variable that comes from outside is now not accessible, but in the assignment we need it. So one way is to make a new local variable or to mark message
as global
, but then we change it outside of the function which might be confusing if the code ever gets extended.
A simple example of this is behavior.
x = 1
def foo():
x = x
return x
This will cause a UnboundLocalError: cannot access local variable 'x' where it is not associated with a value.
While this works.
x = 1
def foo():
global x
x = x
return x
But I agree the code seems weird when one is not aware of this, and it is unintuitive pythonic behavior. I changed the logic a bit to avoid thinking about this.
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.
This will fail.
Are you sure?
The following example seems to suggest otherwise:
In [1]: def deprecated_command(message, version=None):
...: if version is not None:
...: message = f'{message} (this will be removed in v{version})'
...: print(message)
...:
In [2]: deprecated_command('This is a message')
This is a message
In [3]: deprecated_command('This is a message', version=3)
This is a message (this will be removed in v3)
Am I missing anything?
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 the reason why your example works is because the message is given as input argument of the function. The local function structure in the decorator function is important for this to fail, because message needs to be accessed out of the scope of the function.
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.
Ah yeah, I see now. Then it makes sense. Maybe the following change makes it a bit cleaner still:
message = wrap(message if version is None else message + f' (this will be removed in v{version})')
echo.echo(template.render(msg=message, width - 4), width=width)
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 used a different name that is more meaningful to bypass the problem. Let me know what you think. I don't have any strong feelings about this, I just did this already before your comment, it was just not pushed.
I also added use packaging.version.Version
object to standardize the version always to the X.Y.Z format. I follow python's internal logic for versioning Version('1.0') == Version('1.0.0') -> True
. Not sure if this is following some more general versioning specification but at least it is standardized within Python.
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 am actually not sure If should keep this change in this PR, as I don't use it anymore. It could be useful, but I also can store this changes locally and in a PR on my fork.
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 could implement this version logic to in VerdiCommand that requires a new initialization parameter deprecated_version
. I can also put this as an issue so we can get this faster merged and implement the version later as marking a version for 3.0.0
as deprecated is not so urgent.
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 just realized what you meant that this is in the deprecated_command
decorator which is more or less "deprecated" itself, as it is just automatically used by the VerdiCommand
. I agree with you that this doesn't really belong in this PR. Let's just take it out for now and then we can follow up with this later. Probably we need to add an argument to the command
method to declare this version if we think it is useful. And it can then pass this on to echo_deprecated
.
@arguments.PROFILE(required=True, default=None) | ||
def profile_setdefault(profile): | ||
"""Set a profile as the default one.""" | ||
"""Set a profile as the default profile.""" |
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.
Maybe we add the fact that it is deprecated manually such that it shows up in the help text when we do verdi profile --help
?
"""Set a profile as the default profile.""" | |
"""Set a profile as the default profile. (deprecated)""" |
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.
But I don't think we do this for other commands, so maybe it is fine to skip this and keep it as is.
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 think I would use the same method we will use in #6433 once we decided there the way to go
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.
Agreed, let's wrap that one up first, then you can use that method here as well
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 now have the same pattern as in verdi setup
@agoscinski can we wrap this one up for the release? |
fba1216
to
7605bb5
Compare
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #6426 +/- ##
==========================================
+ Coverage 77.51% 77.87% +0.37%
==========================================
Files 560 562 +2
Lines 41444 41808 +364
==========================================
+ Hits 32120 32555 +435
+ Misses 9324 9253 -71
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
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.
All good @agoscinski . Just two open suggestions
e42c5d1
to
72dc8de
Compare
Okay rebased, tests should pass now. Separated this PR into two commits, since the versioning has become a separated feature. |
Thanks @agoscinski but I would prefer to get rid of the first commit. With your previous PR, the So it doesn't make sense to add this new feature to something we are deprecating and no longer using. |
Since verdi user uses set-default, we make the two commands consistent by using set-default for profile and deprecating setdefault. Fix for aiidateam#2910.
72dc8de
to
1ab92bf
Compare
Sure! Makes sense. Just dropped it |
Thanks a lot @agoscinski . As an aside, it is not necessary to add the PR number in the commit message title. This is done automatically when merging through github. Also, we don't really add issue numbers to commit messages. We just add them to the OP of the PR instead. That should be sufficient |
…aiidateam#6426) This is for consistency with `verdi user set-default`.
Fixes #2910
Since
verdi user
usesset-default
, butverdi profile
usessetdefault
, we make the two consistent by using set-default for profile. Old command is marked as deprecated till version 3