[FEATURE] [BREAKING] Change configuration layout

[ingrinder]

Description

This PR is is to enable configuration rearrangement, as in #57.

Apologies that this is in the form of a single squashed commit... however I rebased this branch quite a lot of times and the history was a mess, so it got squashed into one.

While I've provided an implementation here, if you don't think it's suitable we can also use this PR to discuss an alternative.

Reason and / or context

See #57.

Changes

• Configuration completely rearranged.
  • Entries are now specified as dicts containing their type and options keys respective options.
  • All entry-specific options are in the entry's definition thing.
  • Entries can be specified multiple times with different options as a side-effect of this. I may or may not have a plan to try out custom-defined entries with this... 😆
• All Entry subclasses now have entry_options options as an attribute, which contains the entry-specific options.
• The main global configuration now contains configuration only globally applicable.

These changes are all breaking to anybody with a configuration file (as it will now be unusable and crash Archey 😦). This could be very similarly implemented using entries' options as dict values on the keys already present, however this won't allow for the multiple-entry specifying I mentioned earlier.

Alternatively, we could add code to handle old configuration files... With a warning to update it, or automatically convert it to this format? This is still pretty awkard though.

How has this been tested ?

• Still runs on all of my systems fine as far as I can tell.
• All unit tests are passing (after some modification, but nothing breaking).

Types of changes :

• Bug fix (non-breaking change which fixes an issue)
• Typo / style fix (non-breaking change which improves readability)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist :

• [IF NEEDED] I have updated the README.md file accordingly ;
• [IF NEEDED] I have updated the test cases (which pass) accordingly ;
• My changes looks good ;
• I agree that my code may be modified in the future ;
• My code follows the code style of this project (PEP8).

[HorlogeSkynet]

The patch everyone was waiting for !! 😱 Thanks for this, 🙂

As it's a "proposal", what do you think about something like this :

{
	"allow_overriding": true,
	"parallel_loading": true,
	"suppress_warnings": false,
	"entries": [
		{ "User" : true },  // Enabled
		{ "Hostname" : {} },  // Disabled(?)
		{ "Model" : null },  // Disabled
		{ "Distro" : false },  // Disabled
		{ "Kernel" : true },
		{ "Uptime" : true },
		{ "WindowManager" : true },
		{ "DesktopEnvironment" : true },
		{ "Shell" : true },
		{ "Terminal" : true },
		{ "Packages" : true },
		{ "Temperature" : {
				"char_before_unit": " ",  // Options are simple entry's keys
				"sensors_chipsets": [],
				"use_fahrenheit": false
			}
		},
		{ "CPU" : {
				"name" : "Processor"  // Entry name overriding
			}
		},
		{ "GPU" : {
				"one_line": true,
				"max_count": 2,
				"disabled": true  // Disabled(!!) [handy when we temporary wanna hide an entry without losing its config]
			}
		},
		/* ... */

It would remove type & options required explicit definitions, as long as providing "temporary" entry disabling and entry renaming capabilities.

---

OUTDATED : Check below commits description for a simpler proposal.

👋

[HorlogeSkynet]

Hey Michael ! I've postponed the milestone to the end of August, tell me whether you thing it is do-able or not when you can, bye 👋

[HorlogeSkynet]

@ingrinder hey again Michael, do you think you will be able to spare some time in the near future to officially finish ongoing work ? Just tell me whether I should keep up alone or not.
Thanks !! Bye 👋