Split user_interaction.py

[wllacer]

The file is around the 1100 lines big, and there are some modules/classes which should go there but are too big and start to crop everywhere else (i'm thinking in GlobalMenu, and other new specialized menus in the scripts and output_config)
I think time has come to split it and replace with a directory. Not tomorrow, but close by.
In this plan, what I have a clear vision is that we should have to directories with UI related code, and I think there will be consensus around it

• One (current menu) with abstract widget definitions. ( TerminalMenu, Menu, GeneralMenu, ListManager, TextInput, ..., even MiniCurses) Content in there should be as application independent as possible
• The other (with the contents of user_interaction.py, configuration.py and, at least GlobalMenu) which would host the application dependant UI routines.

The trouble starts with how to organize the content in this directory. I don't have a clear guideline, and tbh, not even a firm idea of it. This is the reason i'm starting this discussion.

Ease of migration is a condition "sine qua non". A prerequisite is that users accesing via import archinstall shouldn't notice it. As the rest of the modules goes, i've identified following modules which will need explicit changes

• _init_.py
• lib/disk/filesystems.py
• lib/disk/user_guides.py
• lib/menu/selection_menu.py (mostly GlobalMenu related)
• lib/installer.py

For sure there are obsolete modules we could prune (f.i. MiniCurses is, according to my data, not used anymore in the basis Archinstall code) but after the generic_select fracas (wasn't used in the general code but user routines still do use it), i prefer to be conservative in this regard.

[Torxed]

I welcome this change.
It should be noted that this is at least a days work unless you dig deep and just get on with it. But to do it right it will take some time.

I did a similar split with disk.py -> /disk/<independent files>.py which was a mess.. But in the long run it's better that way.
As you point out, and what I would require, is that this does not affect the import exposure of archinstall.<function>.
This can easily be held true with a __init__.py that exposes each function properly, and the overall __init__.py of the project to import and expose that to general users :)

If you want I can take this on, I don't mind and I have a pretty clear idea of how we could cut the files up into individual ones.
However it will take a little bit of time - things are pretty hectic right now.

[wllacer]

Please yes !. I have the need clear, but not the solution, not even a good idea.
And there is no hurry. In this case, there is no bug to solve, and no "impeding zombie apocalypse", so it is better to be a bit late but correct.

[svartkanin]

Ahh sorry I didn't even realize that there was a discussion going on about this already before raising #1019

[Torxed]

No worries, this is just a discussion. Issue to track the progress is always welcome ^^
I've been occupied quite a bit the last few weeks, but I'll hopefully return to normal operation soon.

[Torxed]

This has been done, the split now lives under lib/user_interaction/* :)
Closing this thread.