-
Notifications
You must be signed in to change notification settings - Fork 2k
Add support for plugin settings to conda config
#14510
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
Conversation
CodSpeed Performance ReportMerging #14510 will not alter performanceComparing Summary
|
|
Getting very close with this one. I think I only need to implement the correct behavior for |
|
I'm working through some changes currently.. |
…sts.plugins.test_config module
|
I appreciate the review, and you have importantly pointed to some gaps in coverage we have (more on that later). But, while the review is appreciated, I do have some problems with your example above. Please allow me to explain... While I do concede that the above does fail, in your example, the A more realistic example for how the import os
from argparse import Namespace
from conda.cli.main_config import _key_exists
from conda.common.configuration import (
Configuration, ParameterLoader, PrimitiveParameter
)
from conda.plugins.config import PluginConfig
class Plugins(PluginConfig):
baz = ParameterLoader(PrimitiveParameter("default"))
class Context(Configuration):
foo = ParameterLoader(PrimitiveParameter(True))
json = ParameterLoader(PrimitiveParameter(True))
def __init__(self, **kwargs):
super().__init__(**kwargs)
self._set_env_vars("TESTER")
@property
def plugins(self):
return Plugins(self.raw_data)
class Args(Namespace):
foo: bool
json: bool
# Plugin configuration values can only come from environment variables
# or config files
os.environ["TESTER_PLUGINS_BAZ"] = "something"
args = Args(foo=False, json=False)
context = Context(argparse_args=args)
assert context.plugins.baz == "something"
assert not context.foo
assert not context.json
assert _key_exists("foo", [], context) # passes
assert _key_exists("plugins.baz", [], context) # passes
assert not _key_exists("missing", [], context) # passes
assert not _key_exists("plugins.missing", [], context) # passesAfter writing the above example, I realized that I hope this can convince you that this pull request is ready to be merged. If you have any more concerns, I'm happy to hear them. |
conda/cli/main_config.py
Outdated
| and rest[0] in context.plugins.parameter_names | ||
| ): | ||
| return True | ||
|
|
||
| if first not in context.list_parameters(): |
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 do we use Configuration.parameter_names for plugins but Configuration.list_parameters() for non-plugins?
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.
We could switch it to use list_parameters instead. I'll do it.
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 must have been an oversight because list_parameters was being used everywhere else in that module.
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.
Address this in my latest commit.
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.
Just a thought, does this mean that parameters cannot be looked up by their aliases?
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.
Yeah, that's true, but you currently cannot do this with normal parameters either, so I'm not worried about it. This is something that should be addressed with a separate pull request.
Co-authored-by: Ken Odegard <[email protected]>
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.
Some more questions, small test correction, and some optional nits
tests/cli/test_config.py
Outdated
| out, err, _ = conda_cli("config", "--file", rc, "--set", key, to_val) | ||
| assert err == f"Unknown key: '{key}'\n" |
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.
So an exception is no longer raised, does this mean the exit code is no longer non-zero?
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, I changed it to no longer raise and exception and return error code, and I will change it back to the way it was.
The reason I changed it originally is that our handling of error codes in conda config is inconsistent. For example, conda config --get does_not_exist does not return a non-zero error code when it probably should.
|
@kenodegard Do you have major concerns about the current state of this PR? |
Co-authored-by: Ken Odegard <[email protected]>
Description
Fixes: #13661
In addition to resolve the issue above, this pull request also performs a little refactoring of the current plugin settings code. These were necessary refactors to make the code work better with the
conda configcommand and the settings system more generally.Checklist - did you ...
newsdirectory (using the template) for the next release's release notes?Add / update outdated documentation?Note for reviewers
The
conda.cli.main_configis definitely in need of a refactor. I tried my best to "spruce" things up a little while I was there, but I intentionally went the easier route while adding the plugin functionality to it because I would like to just ship something that works.