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

CLI: verdi profile setdefault to set-default #6426

Merged

Conversation

agoscinski
Copy link
Contributor

@agoscinski agoscinski commented May 28, 2024

Fixes #2910

Since verdi user uses set-default, but verdi profile uses setdefault, we make the two consistent by using set-default for profile. Old command is marked as deprecated till version 3

@agoscinski agoscinski marked this pull request as ready for review May 28, 2024 14:35
Copy link
Contributor

@sphuber sphuber left a 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

Comment on lines 262 to 264
message_ = message
if version is not None:
message_ = f'{message_} (this will be removed in v{version})'
Copy link
Contributor

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?

Suggested change
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})'

Copy link
Contributor Author

@agoscinski agoscinski Jun 5, 2024

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.

Copy link
Contributor

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?

Copy link
Contributor Author

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.

Copy link
Contributor

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)

Copy link
Contributor Author

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.

Copy link
Contributor Author

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.

Copy link
Contributor Author

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.

Copy link
Contributor

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.

src/aiida/cmdline/commands/cmd_user.py Outdated Show resolved Hide resolved
@arguments.PROFILE(required=True, default=None)
def profile_setdefault(profile):
"""Set a profile as the default one."""
"""Set a profile as the default profile."""
Copy link
Contributor

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?

Suggested change
"""Set a profile as the default profile."""
"""Set a profile as the default profile. (deprecated)"""

Copy link
Contributor

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.

Copy link
Contributor Author

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

Copy link
Contributor

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

Copy link
Contributor Author

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

tests/cmdline/commands/test_profile.py Outdated Show resolved Hide resolved
@sphuber
Copy link
Contributor

sphuber commented Jun 4, 2024

@agoscinski can we wrap this one up for the release?

@agoscinski agoscinski force-pushed the profile-setdefault-to-set-default branch from fba1216 to 7605bb5 Compare June 6, 2024 13:41
@agoscinski agoscinski requested a review from sphuber June 6, 2024 13:42
Copy link

codecov bot commented Jun 6, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 77.87%. Comparing base (ef60b66) to head (1ab92bf).
Report is 112 commits behind head on main.

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     
Flag Coverage Δ
presto 73.20% <62.50%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Copy link
Contributor

@sphuber sphuber left a 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

src/aiida/cmdline/utils/decorators.py Outdated Show resolved Hide resolved
@agoscinski agoscinski force-pushed the profile-setdefault-to-set-default branch from e42c5d1 to 72dc8de Compare June 6, 2024 14:59
@agoscinski
Copy link
Contributor Author

Okay rebased, tests should pass now. Separated this PR into two commits, since the versioning has become a separated feature.

@sphuber
Copy link
Contributor

sphuber commented Jun 6, 2024

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 deprecated_command decorator is no longer needed. I just opened a PR to deprecate it and update all deprecated commands to use your new method: #6461

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.
@agoscinski agoscinski force-pushed the profile-setdefault-to-set-default branch from 72dc8de to 1ab92bf Compare June 6, 2024 15:06
@agoscinski
Copy link
Contributor Author

Sure! Makes sense. Just dropped it

@agoscinski agoscinski requested a review from sphuber June 6, 2024 15:35
@sphuber sphuber merged commit ab48a4f into aiidateam:main Jun 6, 2024
10 of 12 checks passed
@sphuber
Copy link
Contributor

sphuber commented Jun 6, 2024

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

mikibonacci pushed a commit to mikibonacci/aiida-core that referenced this pull request Sep 3, 2024
…aiidateam#6426)

This is for consistency with `verdi user set-default`.
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.

verdi user set-default vs verdi profile setdefault
2 participants