[GRASS-dev] [GRASS GIS] #3790: Cleanup gettext usage for python code

[GRASS GIS]

#3790: Cleanup gettext usage for python code
--------------------------+-------------------------
  Reporter:  pmav99       |      Owner:  grass-dev@…
      Type:  enhancement  |     Status:  reopened
  Priority:  normal       |  Milestone:  7.8.0
 Component:  Python       |    Version:  svn-trunk
Resolution:               |   Keywords:
       CPU:  Unspecified  |   Platform:  Unspecified
--------------------------+-------------------------

Comment (by wenzeslaus):

 Replying to [comment:5 pmav99]:
 > Disclaimer: The real goal of this refactoring was to get rid of
 {{{os.getenv("GISBASE")}}} calls at the module level from all over the
 place. This is a prerequisite for #3772. The scripts and the GUI code
 didn't really need to be touched, but I did them too for uniformity.

 You will have to help me here. Why is the relative path solution from
 #3772 not applicable to the explicit import approach?

 In relation to that, since #3772 is about using `grass` as a standard
 Python package, I think it should follow the "Helman's advice" for a
 Python package.

 > Replying to [comment:4 wenzeslaus]:
 > > The things in lib/python are potentially (and actually) used as Python
 modules by other applications or scripts. Thus from
 https://pymotw.com/2/gettext/index.html#module-localization, it is
 actually the second option which applies:
 > >
 > > > //For a library, or individual module, modifying `__builtins__` is
 not a good idea because you don’t know what conflicts you might introduce
 with an application global value. You can import or re-bind the names of
 translation functions by hand at the top of your module.//
 >
 > ...
 >
 > I am not sure that GRASS was actually following Doug Helman's advice.
 More specifically, almost all GRASS modules used to import the {{{grass}}}
 library before actually calling {{{gettext.install()}}} on their own
 ([https://github.com/GRASS-GIS/grass-
 ci/pull/9/commits/0983ca068d6f7363d2fede26f77b8aed76c87bcc source]). ...
 Anyway, the end result is that most of the time, if not always, as soon as
 you imported the {{{grass}}} lib, the {{{builtins}}} were modified anyway.

 Please read #1739 and #2425 linked from there. I explain that the wxGUI is
 using the practice while the library (lib/python) is not and it should.

 > That being said, I am completely open to any improvements. I am also
 perfectly fine with following Mr. Helman's advice (i.e. by adding explicit
 imports in each and every {{{grass}}} lib module) if someone wants to
 contribute that. But IMHV the proposed implementation is cleaner than the
 previous one.

 Cleaner in which way? I think the registration of the domains separately
 and all at once is a separate issue from "Helman's advice" (which is
 notably also the way which Django is following).

 > > So far we were relatively successful in keeping the GUI separate
 (whether for performance or code organization reasons).
 >
 > I don't really see any coupling of the GUI code with the {{{grass}}}
 library. All the {{{grass}}} library does is registering the "grasswxpy"
 domain. It doesn't import anything.

 It is not just the imports. The idea is that you should be able to install
 GRASS GIS as command line only application without any GUI parts. But
 there is more than one way to deal with this. If the registration of the
 domain can just fail silently, that's probably good enough in this
 particular case. However, as I said, this is a separate issue.

 What is crucial here are the explicit imports versus using builtin. There
 were issues with builtin solution in the past (hence #1739), builtin `_`
 currently causes issues (doctests, static code linting), builtin solution
 is not considered good practice for libraries (Helman, Django) and the
 change breaks wxGUI according to #3838. Thus, I suggest reverting it (at
 least the builtin part) and finding a different solution for #3772.

-- 
Ticket URL: <https://trac.osgeo.org/grass/ticket/3790#comment:10>
GRASS GIS <https://grass.osgeo.org>