added one more solution

Author: franzhaas

README.md

@@ -1,8 +1,8 @@
-# compact testprogram distribution
+# Compact testprogram distribution
 
 Zipapps are a sensible way to be able to distribute test programs with reasonable dependencies.
 
-For executing robotframework in order to perform production facility / test floor automated tasks
+For executing Robot Framework in order to perform production facility / test floor automated tasks
 the dependency list becomes.:
 
  - The operating system
@@ -15,7 +15,7 @@ The only dependency is a python interpreter with a minimum version number, and t
 that only zipapp compatible dependencies can be used.
 
 For python versions 3.10 and 3.11 it is recommended to disable zipimport.zipimporter.invalidate_caches 
-as it has a large performance impact. Disabling it, looses the feature to modify the zipapp during
+as it has a large performance impact. Disabling it, loses the feature to modify the zipapp during
 runtime...
 
 ### Using pdm with pdm-packer
@@ -30,7 +30,7 @@ A python only zipapp without any native code.
 ```
 At this point you are presented with robot output... 
 
-### Minimal Zipapp Build (a.k.a. Limbo Mode)
+### Minimal zipapp build (a.k.a. Limbo Mode)
 
 let’s reduce the size of the zipapp.:
 
@@ -75,39 +75,48 @@ close to the size of a python installer (28MBytes), and is a self contained, sin
 
 cx_freeze does use script entry points.
 
-Robotframework does come with a script, which is documented [here](https://robot-framework.readthedocs.io/en/latest/autodoc/robot.html#module-robot.run).
+Robot Framework does come with a script, which is documented [here](https://robot-framework.readthedocs.io/en/latest/autodoc/robot.html#module-robot.run).
 
 What is not documented (and as far as I understand from this [discussion](https://github.com/robotframework/robotframework/issues/5384) will not be, this
 [pull request](https://github.com/robotframework/robotframework/pull/5390) was provided to remove pythonpathsetter), is that this script needs to live in 
-the source tree, and can not use an installed robotframework, like in the zipapp/frozenapp/etc use case.
+the source tree, and can not use an installed Robot Framework, like in the zipapp/frozenapp/etc use case.
 
 ### background
-It is possible to use robotframework straight from the source tree, without installation or configuring PYTHONPATH. This feature is not documented in the 
+It is possible to use Robot Framework straight from the source tree, without installation or configuring PYTHONPATH. This feature is not documented in the 
 end user documentation, and not explained in the CONTRIBUTING.rst.
 
-This is implemented using the `pythonpathsetter` module which can be loaded by `import pythonpathsetter` when the robotframework is run from the script,
-additionally by `import robot.pythonpathsetter` when the script runs inside an environment where robotframework was installed into, and only using 
+This is implemented using the `pythonpathsetter` module which can be loaded by `import pythonpathsetter` when the Robot Framework is run from the script,
+additionally by `import robot.pythonpathsetter` when the script runs inside an environment where Robot Framework was installed into, and only using 
 `import robot.pythonpathsetter`. This module changes the the `sys.path` at runtime, which can cause severe confusion when debugging dependency issues.
 
 These are the symptoms to look out for.:
- 1 is that robotframework fails, as pythonpathsetter can not be imported. 
+ 1 is that Robot Framework fails, as pythonpathsetter can not be imported. 
  2 you can use ```import robot; robot.run()``` when debugging from a REPL.
 
  In total at the time of writing there are 34 instances of ```sys.path``` and 89 ```__file__```in the source, all of them bring the risk of causing issues 
  with zipapp/frozenapp usage. When I went over the source the first time, I missed how the ```pythonpathsetter``` can cause issues.
 
 ### solutions
 #### make sure pythonpathsetter exits
-Install a  ```pythonpathsetter.py``` into your environment. Be aware future releases of robotframework will call a ```pythonpathsetter.set_pythonpath``` 
-which is in the source tree where you would expect ```robot.pythonpathsetter.set_pythonpath```. It doesnt need to do anything but if it is missing the code 
+Install a  ```pythonpathsetter.py``` into your environment. Be aware future releases of Robot Framework will call a ```pythonpathsetter.set_pythonpath``` fucntion.
+This function is in the source tree where you would expect ```robot.pythonpathsetter.set_pythonpath```. It doesn’t need to do anything but if it is missing the code 
 will not work. This change is introduced in response to linter messages.
 
-#### do not use robotframework distributed scripts
+#### do not use Robot Framework distributed scripts
 Provide your own start script.
 
+#### [merge](https://github.com/robotframework/robotframework/pull/5390) (would need to come from upstream)
+Apart of improving the situation for frozenapp/zipapp use cases this brings these advantages.:
+
+ 1) Reduction of total complexity (cyclomatic complexity goes from 18329 to 18307 a delta of 22, number of lines from 58033 to 57967, a delta of 134)
+ 2) The ```pythonpathsetter``` feature is not advertised. It is likely that its most common use is in Robot Framework quality control.
+    - if that would make testing easier/faster for multiple python installations that might be worth the risk.
+    - solutions like [uvx](https://docs.astral.sh/uv/) ```uvx --python 3.14 --from . --reinstall robot``` are available, taking care of warehousing the python versions
+ It is hard to get this point across, but the "unpack into a directory" distribution method is very much outdated by now.
+
 #### do not modify the ```sys.path``` (would need to come from upstream)
 Placing this code into the src directory, next to the robot directory of the source distribution. Using this code allows the robot code base to reduce 
-the modifications of the ```sys.path```, while keeping the feature to use robotframework straight from the source directory.
+the modifications of the ```sys.path```, while keeping the feature to use Robot Framework straight from the source directory.
 
 ```python
 import pathlib
@@ -118,13 +127,13 @@ if __name__ == "__main__":
         with source.open() as run:
             source_code = run.read()
     except Exception as e:
-        print(f"""run_rf is a tool allowing you to start robotframework from a source tree without installing anything. Exception {e} occurred.
+        print(f"""run_rf is a tool allowing you to start Robot Framework from a source tree without installing anything. Exception {e} occurred.
               
-              This script should not be used outside of robotframework development, and is not part of robotframework itself.""")
+              This script should not be used outside of Robot Framework development, and is not part of Robot Framework itself.""")
     exec(source_code)
 ```
 
-### consequence
+### conclusion
 There are alternatives available.
 
  - docker (way more heavy weight, user rights need to be managed)