agent: add argument to specify python virutal env

[nvincent-vossloh]

When using agentwrapper, the python packages used are the one installed on the machine.
This commit add an argument to specify the path to a virtual env which will be used by the agent.

Description

Checklist

• Documentation for the feature
  I have not seen documentation about AgentWrapper (git grep -i agentwrapper did not yield any .rst)
• Tests for the feature
  I would need help with that

• The arguments and description in doc/configuration.rst have been updated
  Not applicable as far as I understand

• Add a section on how to use the feature to doc/usage.rst
  Let me know if you think this is necessary, I think it is an advanced feature which might be confusing for first time readers.

• Add a section on how to use the feature to doc/development.rst
  Not applicable

• PR has been tested
  I tested with our internal fork of labgrid which adds a driver to make https requests from the exporter to the DUT.

• Man pages have been regenerated
  Not applicable

I developped this feature in order to be able to use the urllib3 module pinned at a version (see #1301 (comment)).
The driver using this feature is not (yet) public but a first version is available here:
SiemaApplications-attic@81918df

Here is the modification added to the above patch in order to be able to specify the virtual env necessary for pyrequests labgrid driver:

commit 921bd05c2668993dfb64342d78898d215ecd9a86
Author: Nicolas VINCENT <nicolas.vincent@vossloh.com>
Date:   Fri May 24 11:37:13 2024 +0200

    pyrequest: Adds option to specify virtual env
    
    adds pyvirtenv option to be able to specify the virtual env used by
    pyrequests
    
    Signed-off-by: Nicolas VINCENT <nicolas.vincent@vossloh.com>

diff --git a/labgrid/driver/pyrequestsdriver.py b/labgrid/driver/pyrequestsdriver.py
index 0de22b6..f07e6d6 100644
--- a/labgrid/driver/pyrequestsdriver.py
+++ b/labgrid/driver/pyrequestsdriver.py
@@ -17,6 +18,8 @@ class PyRequestsDriver(Driver):
     bindings = {
         "iface": {"RemoteNetworkInterface", "NetworkInterface", "USBNetworkInterface"},
     }
+    pyvirtenv = attr.ib(default=None,
+                        validator=attr.validators.optional(attr.validators.instance_of(str)))
 
     def __attrs_post_init__(self):
         super().__attrs_post_init__()
@@ -27,7 +30,7 @@ class PyRequestsDriver(Driver):
             host = self.iface.host
         else:
             host = None
-        self.wrapper = AgentWrapper(host)
+        self.wrapper = AgentWrapper(host, self.pyvirtenv)
         self.proxy = self.wrapper.load('pyrequests')
 
     def on_deactivate(self):

Then the env yaml file use looks like this:

- targets:
  main:
    drivers:
      - PyRequestsDRiver:
        pyvirtenv: '/path/to/virt/env/'

I tried to run developper test without success... tox would return an error and I did not know which env file to provide to pytest.

I did not know if I should update all drivers using an instance of AgentWrapper in order to use this new feature. Just let me know.

I feel a little bit embarrassed with this PR as I have not been able to test it and document it according to the development guidelines, my intent is not to burden you but rather to give something back to this project.

Thanks in advance for your guidance.

[jluebbe]

The intent of the agent functionality is to avoid having any dependencies on the exporter, which is the opposite of what this PR would introduce: a specific (likely manually deployed) venv would be needed. As mentioned in #1301 (reply in thread), it should be easier to solve b by using the existing port forwarding functionality to run the HTTP client in the context of the labgrid client instead of on the exporter.

That way, you can use the full functionality of requests, e.g. configuring the certificate validation, such as verify=False on the request or session.

[nvincent-vossloh]

Yes that make sense, the only downside I encounter so far, is the client is not able to provide a certificate to verify the connection and must pass verify=False. If you have a trick up your sleeve for that case I would happy to hear it 🙂

In the mean time, I guess this PR can be closed. Thanks again for your help, and sorry for the trouble.