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

[internal] Somewhat simplify config parsing #14699

Merged
merged 2 commits into from
Mar 4, 2022

Conversation

benjyw
Copy link
Contributor

@benjyw benjyw commented Mar 4, 2022

  • Simplify Config.get to always return a string.

    It was being used that way in practice everywhere within
    the options system (which does the type conversion later).

    The only place Config.get was used for type conversion was
    in the special case of cli.alias, which the options bootstrapper
    reads directly from config. So the conversion in that one
    case was inlined.

    As a byproduct, gets rid of the default= arg to Config.get,
    and always returns None if the value doesn't exist, since
    the default= arg was, again, only used in that one special case.

  • Fix the type signature of get_value, which can never
    in fact return None.

  • Use our own exception types and constants, instead of
    borrowing the ones from configparser, now that ini parsing is
    a distant memory.

This makes the Config class easier to reason about.

[ci skip-rust]

[ci skip-build-wheels]

- Simplify Config.get to always return a string.

  It was being used that way in practice everywhere within
  the options system (which does the type conversion later).

  The only place Config.get was used for type conversion was
  in the special case of cli.alias, which the options bootstrapper
  reads directly from config. So the conversion in that one
  case was inlined.

  As a byproduct, gets rid of the default= arg to Config.get,
  and always returns None if the value doesn't exist, since
  the default= arg was, again, only used in that one special case.

- Fix the type signature of get_value, which can never
  in fact return None.

- Use our own exception types instead of borrowing the ones from
  configparser, now that ini parsing is a distant memory.

This makes the Config class easier to reason about.

[ci skip-rust]

[ci skip-build-wheels]
@benjyw
Copy link
Contributor Author

benjyw commented Mar 4, 2022

This is pre-work to make it simpler to tackle #14679

# Rust tests and lints will be skipped. Delete if not intended.
[ci skip-rust]

# Building wheels and fs_util will be skipped. Delete if not intended.
[ci skip-build-wheels]
Copy link
Contributor

@Eric-Arellano Eric-Arellano left a comment

Choose a reason for hiding this comment

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

Yay! Bye bye configparser.

If it helps at all, I think it's very reasonable to get rid of our abstract class for Config vs our Toml implementation. It seems very very unlikely we'll want to support more config file formats. Right now there's over-generalization, like the difference from .get() vs .get_value() is unnecessary.

def get(self, section, option, type_=str, default=None):
"""Retrieves option from the specified section (or 'DEFAULT') and attempts to parse it as
type.
def get(self, section, option) -> str | None:
Copy link
Contributor

Choose a reason for hiding this comment

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

This should probably have type hints too:

Suggested change
def get(self, section, option) -> str | None:
def get(self, section: str, option: str) -> str | None:

Copy link
Contributor

Choose a reason for hiding this comment

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

Fine to do in followup

@Eric-Arellano
Copy link
Contributor

Btw this should be [internal]

@benjyw benjyw changed the title Somewhat simplify config parsing [internal] Somewhat simplify config parsing Mar 4, 2022
@benjyw benjyw merged commit be36ed0 into pantsbuild:main Mar 4, 2022
@benjyw benjyw deleted the simplify_config branch March 4, 2022 20:40
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.

2 participants