Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

@travishathaway
Copy link
Contributor

@travishathaway travishathaway commented Jan 22, 2025

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 config command and the settings system more generally.

Checklist - did you ...

Note for reviewers

The conda.cli.main_config is 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.

@conda-bot conda-bot added the cla-signed [bot] added once the contributor has signed the CLA label Jan 22, 2025
@codspeed-hq
Copy link

codspeed-hq bot commented Jan 22, 2025

CodSpeed Performance Report

Merging #14510 will not alter performance

Comparing travishathaway:issue-13661 (1ce4f4d) with main (91895ab)

Summary

✅ 21 untouched benchmarks

@travishathaway
Copy link
Contributor Author

Getting very close with this one. I think I only need to implement the correct behavior for conda config --show and conda config --show-sources.

@travishathaway travishathaway marked this pull request as ready for review January 23, 2025 11:49
@travishathaway travishathaway requested a review from a team as a code owner January 23, 2025 11:49
@jezdez jezdez self-requested a review February 5, 2025 15:35
@jezdez jezdez self-assigned this Mar 6, 2025
@jezdez
Copy link
Member

jezdez commented Mar 6, 2025

I'm working through some changes currently..

@travishathaway
Copy link
Contributor Author

travishathaway commented Apr 23, 2025

@kenodegard,

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 _key_exists function is not being used in the correct context. On the Context class, parameters are special types of objects (ParameterLoader). Because of this, plugins will never be returned by the list_parameters method and when that's true, the _key_exists function works as expected.

A more realistic example for how the Configuration classes are being used in conda would be the following:

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) # passes

After writing the above example, I realized that _key_exists is not being directly tested in our test suite. Thanks for helping point this out. To address this, I added the following test to our test suite. See the commit below for details:

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.

Comment on lines 389 to 393
and rest[0] in context.plugins.parameter_names
):
return True

if first not in context.list_parameters():
Copy link
Contributor

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?

Copy link
Contributor Author

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.

Copy link
Contributor Author

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.

Copy link
Contributor Author

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.

Copy link
Contributor

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?

Copy link
Contributor Author

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.

Copy link
Contributor

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

Comment on lines 467 to 468
out, err, _ = conda_cli("config", "--file", rc, "--set", key, to_val)
assert err == f"Unknown key: '{key}'\n"
Copy link
Contributor

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?

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, 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.

@jezdez jezdez requested a review from kenodegard April 30, 2025 19:02
@jezdez
Copy link
Member

jezdez commented Apr 30, 2025

@kenodegard Do you have major concerns about the current state of this PR?

@jezdez jezdez removed their assignment Apr 30, 2025
kenodegard
kenodegard previously approved these changes May 8, 2025
@github-project-automation github-project-automation bot moved this from 🏗️ In Progress to ✅ Approved in 🔎 Review May 8, 2025
jezdez
jezdez previously approved these changes May 8, 2025
@jezdez jezdez merged commit af55622 into conda:main May 9, 2025
74 checks passed
@github-project-automation github-project-automation bot moved this from ✅ Approved to 🏁 Done in 🔎 Review May 9, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

cla-signed [bot] added once the contributor has signed the CLA

Projects

Archived in project

Development

Successfully merging this pull request may close these issues.

Add better integration of settings plugin hook into conda config

4 participants