Split __main__.py across different files

[n0toose]

If everything is under one file, syncMyMoodle will keep getting progressively harder to maintain and modify.

A better approach would be keeping the core functionality of main() under __main__.py and putting things like class definitions to other files. The goal here would be making the code even more "OOP"-like than it already is and improve modularity. This should help with developing additional extensions in the long run.

[septatrix]

This is already partially done on the v2 branch (on which I haven't worked in ages).
My eventual goal which is not yet implemented on v2 would be to provide a decorator which can register handers for each module and pass in the session

[n0toose]

Is it possible for us to eventually apply some of your work onto the main branch?

[D-VR]

This will be my next focus, as the current monolithic file is basically unmaintainable and makes it hard to understand the codebase.

It's probably scaring off any future would be contributors.

I've already started working on a new structure for syncmymoodle, with the following goals:

• Make components modular and class based
• Split off different actions into their own submodules (like authentication, downloading from different services, parsing pages/services)
• Keep all the current features and behaviors
• Hopefully keep git history intact as much as possible, which is not very easy when splitting a single file into >10 new ones

This is what I propose, in the future we can still move stuff around and rename things, but it should be a lot easier after this major initial refactoring:

.
├── app.py
├── auth
│   ├── base.py
│   └── rwth_sso.py
├── clients
│   ├── base.py
│   └── rwth.py
├── cli.py
├── config.py
├── constants.py
├── downloader
│   ├── handlers
│   │   ├── __init__.py
│   │   ├── opencast.py
│   │   ├── quiz.py
│   │   └── youtube.py
│   ├── manager.py
│   └── utilities.py
├── __init__.py
├── logging.py
├── __main__.py
├── nodes.py
├── parsers
│   ├── courses.py
│   └── links.py
├── secret_managers
│   ├── base.py
│   └── keyring_manager.py
└── utils
    ├── dependencies.py
    ├── pickle_helpers.py
    └── totp.py

[septatrix]

Don't make it too fine grained, we are not in Java where one class equals one file. Auth can be one file, clients likely as well, cli can be put into main, logging likely does not need to exist at all, secret managers can be one file and utils as well

[D-VR]

Don't make it too fine grained, we are not in Java where one class equals one file. Auth can be one file, clients likely as well, cli can be put into main, logging likely does not need to exist at all, secret managers can be one file and utils as well

Yeah I understand that this might be a little fine grained, however for future extensibility I think it makes sense to have one API/Interface/base Class and separate any logic which handles just one service into it's own file.

Here is the reasoning for each one:

• For Auth, as different services may need separate Auth flows/configuration, while we currently only support RWTH SSO with Moodle there are atleast two open issues which ask for Auth support for different services/plattforms, and there was hope to make this project accessible for other Universities as well.
• This also counts for clients, as different universities might have different structures / flows.
• For secret managers, I have the idea in my head to expand those soon to cover 1Password and Bitwarden, so splitting it now makes it easier to manage later.

I propose having one logging class/factory file so we have a single point to configure for the entire project, however it's probably better suited to be in /utils

I agree that we can probable aggregate all the current utils into a single file, as there are not that many.

If we ever want to make a GUI, I think it makes sense to split CLI off now, as this keeps the main/app clean.