Open wenzeslaus opened 1 month ago
The cherry on top would be that doing
python -m grass
Would simply open the grass application (either console or gui, depending on where we are at).
All it takes is a __main__.py
file, which calls what it needs to start GRASS (as an application). That's what things like unittest to have it run like an app but also like a module
To be clear about the goal of some of the refactoring PRs for
lib/init/grass.py
: Thelib/init/grass.py
file is currently very long with a lot of code accumulated over the years. While the structure of the code improved over years, the functionality is not available for reuse elsewhere.I'm aiming at refactoring of some of the code there so that the functionality can be reused in grass.script.setup. In simplified terms, the
lib/init/grass.py
file should look like this:I'm not saying that's what I will achieve because that's not currently my goal, but that's the idea in terms of dependencies. Nothing depends or should depend on
lib/init/grass.py
. There should be only limited code inlib/init/grass.py
. Most of it should be in grass.app, grass.grassdb, and grass.script.What I'm aiming at is having all the initialization functions in the library, that includes runtime, session files, locking, project management, but does not necessarily include functionality related to the main grass executable only such as command line parameters and interactive-only components.