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

Prepare Loader and MemoryLoader for TOML support #3344

Closed
wants to merge 3 commits into from

Conversation

ziima
Copy link
Contributor

@ziima ziima commented Sep 15, 2024

  • ran the linter to address style issues (tox -e fix)
  • wrote descriptive pull request text
  • ensured there are test(s) validating the fix
  • added news fragment in docs/changelog folder
  • updated/extended the documentation

def __init__(self, **kwargs: Any) -> None:
super().__init__(Section(prefix="<memory>", name=str(id(self))), [])
self.raw: dict[str, Any] = {**kwargs}
def __init__(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a backwards incompatible change and cannot happen.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, we could have cleared this in #3309. Anyway, he are reasons why I did it:

  • MemoryLoader is not listed in API docs: https://tox.wiki/en/latest/plugins_api.html Hence, I assumed it may have incompatible changes.
  • MemoryLoader.__init__ isn't currently compatible with the documented API for Loader.__init__.

I can add some compatible layer and/or deprecation warnings, but I need to know how to handle it correctly. More incompatible changes will be needed for TOML support.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oversight.

  • MemoryLoader.__init__ isn't currently compatible with the documented API for Loader.__init__.

By design. It is meant to be instantiated with the appropriate values. Why would a child class be compatible with its parent constructor? The substitution principle works in the other way around, I believe.

Copy link
Contributor Author

@ziima ziima Sep 23, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The compatibility makes the child class more flexible, especially when some of the omitted arguments become needed such as in this case.

Now, I'm not quite sure which way use to make it compatible. It seems to me it would be best to create new MemoryLoader class with modified constructor and deprecate current one. Is that OK?

Copy link
Member

@gaborbernat gaborbernat Sep 23, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I disagree. Why does a memory loader need to know about its section? Or overrides. These are concepts that do not make sense in this context, so I am not sure why you are trying to force it into?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the MemoryLoader is part of public API it should we able to handle various sorts of configs, such as complete config of tox. In such case, it needs to know which section it should extract the key from and whether to apply any overrides.

Or do I not get the purpose of MemoryLoader correctly?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I hope you reach an agreement here. I see the reasoning for having to access these bits, we use it in tox-ansible plugin. At the same time, I would try to avoid breaking changes (changing signature does not always count as breaking in my eyes).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel like overrides should be their own loader 🤔 and not depend on the config source. 🤔

Copy link
Member

@gaborbernat gaborbernat Sep 27, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, I looked into this, overrides are intended to be not enabled for a memory loader. And I guess what I am not understanding is why you want to change that? The TOML loader should not be a memory loader.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here is an implementation demonstrating there is no need for this #3353, will continue over the next week to get it in a ready to ship state 👍

@gaborbernat gaborbernat marked this pull request as draft September 16, 2024 18:06
This was referenced Sep 27, 2024
@gaborbernat
Copy link
Member

Replaced by #3353

@gaborbernat gaborbernat closed this Oct 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants