grass.script: Make setup available without another import #2451
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
import grass.script.setup or similar was needed to get access to functions in the setup module. Now the module is imported in the init file which makes it available without an additional import in user code. gs.setup.init() is now an easy and clear way of getting access to the init function. Most of the code using grass.script.setup was modified to the new style (except for grass.py and imports of specific functions). Documentation related to the session returned from gs.setup.init updated as gs.setup.finish() call is not even needed with session.finish() call is easier. (Using session.finish() leaves gs.setup.init() call to be the only one from setup for typical session handling code, so the previsouly required separate import would be for one call only; now there is no import except for grass.script.) Alternative would be to import all functions (which would bring many symbols to gs) and importing specific functions (e.g., init only), but importing init makes it most clear (all are available) while keeping them separate under setup (although there are other setup or session related functions in grass.script.core already available after importing grass.script).
ninsbl
pushed a commit
to ninsbl/grass
that referenced
this pull request
Oct 26, 2022
import grass.script.setup or similar was needed to get access to functions in the setup module. Now the module is imported in the init file which makes it available without an additional import in user code. gs.setup.init() is now an easy and clear way of getting access to the init function. Most of the code using grass.script.setup was modified to the new style (except for grass.py and imports of specific functions). Documentation related to the session returned from gs.setup.init updated as gs.setup.finish() call is not even needed when easier session.finish() call is used instead. (Using session.finish() leaves gs.setup.init() call to be the only one from setup for typical session handling code, so the previously required separate import would be for one call only; now there is no import except for grass.script.) Alternatives to this implementation would be to import all functions (which would bring many symbols to grass.script) or importing specific functions (e.g., init only), but importing setup makes it most clear (all are available) while keeping them separate under setup. (There are other setup or session related functions in grass.script.core already available after importing grass.script, so there is still some confusion related to that. However, rather than mixing all together, it seems that these need to be separated from core or organized better in some other way.)
ninsbl
pushed a commit
to ninsbl/grass
that referenced
this pull request
Feb 17, 2023
import grass.script.setup or similar was needed to get access to functions in the setup module. Now the module is imported in the init file which makes it available without an additional import in user code. gs.setup.init() is now an easy and clear way of getting access to the init function. Most of the code using grass.script.setup was modified to the new style (except for grass.py and imports of specific functions). Documentation related to the session returned from gs.setup.init updated as gs.setup.finish() call is not even needed when easier session.finish() call is used instead. (Using session.finish() leaves gs.setup.init() call to be the only one from setup for typical session handling code, so the previously required separate import would be for one call only; now there is no import except for grass.script.) Alternatives to this implementation would be to import all functions (which would bring many symbols to grass.script) or importing specific functions (e.g., init only), but importing setup makes it most clear (all are available) while keeping them separate under setup. (There are other setup or session related functions in grass.script.core already available after importing grass.script, so there is still some confusion related to that. However, rather than mixing all together, it seems that these need to be separated from core or organized better in some other way.)
neteler
pushed a commit
to nilason/grass
that referenced
this pull request
Nov 7, 2023
import grass.script.setup or similar was needed to get access to functions in the setup module. Now the module is imported in the init file which makes it available without an additional import in user code. gs.setup.init() is now an easy and clear way of getting access to the init function. Most of the code using grass.script.setup was modified to the new style (except for grass.py and imports of specific functions). Documentation related to the session returned from gs.setup.init updated as gs.setup.finish() call is not even needed when easier session.finish() call is used instead. (Using session.finish() leaves gs.setup.init() call to be the only one from setup for typical session handling code, so the previously required separate import would be for one call only; now there is no import except for grass.script.) Alternatives to this implementation would be to import all functions (which would bring many symbols to grass.script) or importing specific functions (e.g., init only), but importing setup makes it most clear (all are available) while keeping them separate under setup. (There are other setup or session related functions in grass.script.core already available after importing grass.script, so there is still some confusion related to that. However, rather than mixing all together, it seems that these need to be separated from core or organized better in some other way.)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
import grass.script.setup or similar was needed to get access to functions in the setup module. Now the module is imported in the init file which makes it available without an additional import in user code. gs.setup.init() is now an easy and clear way of getting access to the init function.
Most of the code using grass.script.setup was modified to the new style (except for grass.py and imports of specific functions).
Documentation related to the session returned from gs.setup.init updated as gs.setup.finish() call is not even needed when easier session.finish() call is used instead. (Using session.finish() leaves gs.setup.init() call to be the only one from setup for typical session handling code, so the previously required separate import would be for one call only; now there is no import except for grass.script.)
Alternatives to this implementation would be to import all functions (which would bring many symbols to grass.script) or importing specific functions (e.g., init only), but importing setup makes it most clear (all are available) while keeping them separate under setup. (There are other setup or session related functions in grass.script.core already available after importing grass.script, so there is still some confusion related to that. However, rather than mixing all together, it seems that these need to be separated from core or organized better in some other way.)