Remove singleton in config.Config

[lucc]

This makes the Config class easier to understand. Also see commit message of c9a6330.

[lucc]

@scheibler if you only have little time to spare for khard atm I would ask you to have a look at this PR first. It is very small in terms of functional changes (all of them are in c9a6330, the others are just formatting).

The second reason why I ask you to prefer this PR is that it makes rebasing and mergeing with other changes very hard (because of c3388e5) so I would like to see it merged before I have to rebase and merge it after some other PRs.

[scheibler]

Okay. If you are sure, that we don't need the config in other parts of the code, I will include this pr.

But should there be another release 0.11.3 before, which pins the vobject version to 0.9.2 like
suggested in #87? Although my regexp is not perfect, it works for most contacts whereas the current
situation with vobject 0.9.3 is as bad as without my workaround. I don't see another solution at
this time but to downgrade the library until they fixed the issue.

[lucc]

Currently we do not use the config instance in any other module of khard. Any future changes to this pattern are also decisions to change it. So I would answer "we don't". Also because I think it is a nice design pattern to divide the functionality of a program as clear as possible:

• library/backend is ignorant of the rest, all options are passed as function arguments,
• the config code parses the config file and does not know what the values will be used for (doesn't know anything about the rest)
• similar for the command line interface
• main calls the cli parser, and the config parser and somehow handles the merging of these (for us main sets options in the config instance but that is fine as the logic is in main and not in config), then it calls the library and passes the correct function arguments

Such a design pattern makes it easier in my opinion to understand what happens where. It also makes it possible to use parts of the code from another program (in the future it might be possible to use the khard library part from another python script or even write a tui/gui for it (for me the library part is khard/{adress_book,carddav_object,helpers,object_type}.py).

I do not have an opinion about releasing 0.11.3 or freezing vobject. But I have a question about development: are you going to use the develop branch for development from now on (did you switch to a git-flow like pattern)? Should I make all further PRs for develop?

[scheibler]

I agree on your design pattern explanation.

Should I make all further PRs for develop?

Yes.

[lucc]

I also noticed that we really need to remove the singleton stuff in order to be able to write proper tests as it will mess up the separation of test cases. Try this test:

import unittest
from khard import config


class ConfigStuff(unittest.TestCase):

    def test_config_singleton(self):
        c = config.Config()
        self.assertEqual(c.get_preferred_vcard_version(), "4.0")#or 3.0 depending on your config
        c.set_preferred_vcard_version('11')
        self.assertEqual(c.get_preferred_vcard_version(), "11")

    def test_config_singleton2(self):
        c = config.Config()
        self.assertEqual(c.get_preferred_vcard_version(), "4.0")# or 3.0 depending on your config
        c.set_preferred_vcard_version('22')
        self.assertEqual(c.get_preferred_vcard_version(), "22")


if __name__ == "__main__":
    unittest.main()

The test also fails if I put the two functions in separate classes and also if I put the classes in separate files. Save the file(s) as test_something.py and run python -m unittest.

[lucc]

I chenged the merge target to develop but github doesn't understand that you merged this already. Should we close it?

[scheibler]

Okay, I thought, that you've been notified about merging automatically. Yes, can be closed.