eugenetriguba / config-file Goto Github PK

In ConfigFile where we're using the custom parser if one is passed in, it checks to ensure that it is not None and that it is not abstract. However, it should also make sure that the passed in parser is an implementation of BaseParser. For some reason, the tests are failing and the conditional is not being entered if we just tack on and isinstance(parser, BaseParser) in __determine_parser().

Python's configparser with the ini format does not allow duplicate keys. Furthermore, toml and yaml do not either. It does not make sense to have a way to get all the values for a specified key if json is the only format that allows it since you would have to raise errors for all other file types if it is used.

Dependabot can't resolve your Python dependency files.

As a result, Dependabot couldn't update your dependencies.

The error Dependabot encountered was:

Creating virtualenv config-file-Ws6y9HXu-py3.8 in /home/dependabot/.cache/pypoetry/virtualenvs
Updating dependencies
Resolving dependencies...

[PackageNotFound]
Package toml (0.10.0) not found.

If you think the above is an error on Dependabot's side please don't hesitate to get in touch - we'll do whatever we can to fix it.

View the update logs.

What if someone wants to get and have a default of None? Since it is checked to be not None for it to be used, that is currently not possible.

I'm leaving this here as something I may like to do, but that is not urgent or a high priority at the moment. With Python's configparser, that are a few things I find that it lacks.

1. Support for sub-sections
2. Support for retrieving values in the types they were set as, not always strings.
3. Comment support (possible with configparser but hacky and quirky in behavior)

This makes the interaction between using the ini parser and all parsers a bit odd since
with the ini parser, everything you retrieve is always a string, but with the others, they retrieve
the type they were set as. The only thing not retrieved as a string are sections, which are retrieved
as dictionaries. However, that isn't configparser's doing. This package does that.

The yaml and toml file formats have still yet to be supported. This should be done before v1.

In test_parse_value.py, we have a test case with this input:

(
     {"blah": {"blah2": {"blah3": "false"}, "abc": "5.25", "boo": "tRuE"}},
     {"blah": {"blah2": {"blah3": False}, "abc": 5.25, "boo": True}}
)

If we change the value of "blah3" to "fAlSe", the test fails. However, inputting "fAlSe" in for can_be_parsed_as_bool() yields True and inputting it in for parse_value by itself yields False, which are both the outputs we'd expect. So it must be something to do with the dict conditional in parse_value.

However, "boo" and "false" in "blah3" are still getting parsed correctly. The strtobool call in parse_value lower()s its input as well as can_be_parsed_as_bool() so it shouldn't be a case issue.

Right now, what parsers are used are hard-coded to look at the extension and determine from that. However, there are plenty of cases where there may not be an extension or it may have a .ini file syntax but its extension is .conf and so on.

I'd like to allow overriding that automatically determined parser with a keyword argument when instantiated the ConfigFile object. Something along the lines of:

from config_file import ConfigFile

config = ConfigFile("some-config.conf", parser="ini")

It is worth considering whether or not the value for the parser keyword should be a string or an enum that specifies the parsers that are available. I lean towards string since it is more operable with having parsers from plugins used (#17).

The regular sphinx syntax for docstrings isn't the nicest to read. The google format feels more natural. With the napolean extension, it should still be possible to parse them using sphinx.

A separate space for the docs would be ideal. Ideas I've had so far are possibly Slate, read the docs with Sphinx, or a separate website. A decision on any has not been made.

The documentation on readthedocs is not super useful besides a quick usage example. However, the API reference is blank. I'd prefer to make that the go-to place to get information about the project.

That includes:

• The contents of the README -- this has been updated with meaningful usage information
• [] The license file
• [] The code of conduct file
• [] The changelog
• [] An api reference
• [] in-dpeth usage instructions
• [] How file types differ with how ConfigFile handles them.

The package should support reading & writing to .env files.

This would likely involve writing a custom parser for it, which shouldn't be too difficult considering the syntax is simple.

Furthermore, it is worth considering whether or not the environment variables should be updated to what is in the .env file we have read in when a ConfigFile object is constructed with a .env file passed in.

This would allow indexing the ConfigFile object to manipulate it if desired.

Starting file

[section]
list_key = [1, 2]

from config_file import ConfigFile

config = ConfigFile('~/some-path/some-file.ini')

config['section']['list_key'] = ['new_list']
config['section']['int_key'] = 5
del config['section']['list_key']
config.save()

Ending file

[section]
int_key = 5

Python's configparser interprets everything as a string. However, when we are setting keys, the underlying data structure is just a dictionary. Therefore, if we set a value such as config.set('key', 5), a subsequent call to retrieve that value config.get(''key') would return 5, not '5'. However, if we create a brand new ConfigFile object and re-read that file in and get the 'key' again, it will return '5' because configparser re-read the file in. So when we set keys with the INI parser, they should be converted to strings first.

ConfigFile("file-path", parser=CustomParser) feels pretty clunky every instantiation of the object. Furthermore, the regular user of the package would have to create this custom parser.

It would be nice to support hooks into the package, likely inside __determine_parser(), which would allow for plugins. That way we could have that plugin expose a parser that is automatically used by ConfigFile for a specified file type.