podman module import time is quite slow at ~200 ms

[djasa]

I'm adding podman module to nmci, an internal python library for NetworkManager testing. The library is imported in at least 2 commands run per test in a suite with some 1500 tests. The difference of import time of nmci with and without podman is at around 200 ms, which means that use of plain import podman at the beginning of one of the .py files would add non-negligible 10 min to the test suite run time.

A workaround is to conditionally import podman, however the use of the module is then much less straightforward.

a basic look into python3 -X importtime -c 'import podman' shows:

• podman itself is (as expected) small and fast but its dependencies are slow:

  import time:       481 |     227113 | podman
  

• the slowest dependencies are requests and urllib3:

  import time:       611 |      67090 |           urllib3
  import time:       733 |     137892 |         requests
  

• just loading requests takes a bit under 200 ms:

  $ python3 -X importtime -c 'import requests' 2>&1 | sed -n '1p; $p'
  import time: self [us] | cumulative | imported package
  import time:       766 |     190204 | requests
  

So maybe the easiest short-term solution could be a delayed loading of requests and long-term replacing it with a leaner library?

Numbers are from a laptop with Fedora 41, respective versions are:

python3-3.13.0~rc1-2.fc41.x86_64
python3-podman-5.2.0-1.fc41.noarch
python3-requests-2.32.3-3.fc41.noarch
python3-urllib3-1.26.19-2.fc41.noarch

[inknos]

Hey, firstly, thanks a lot for using podman.

Interesting report. Surely something worth considering for your use case and for podman's future in general.

So maybe the easiest short-term solution could be a delayed loading of requests and long-term replacing it with a leaner library?

1. Lazy loading is indeed the most viable option, although I am not sure at what point requests are actually called and, AFAIK, lazy loading is tricky in python in some instances (even the PEP 690 was rejected, and it makes me thoughtful about it).

   But honestly, I am not an expert about this kind of optimization, so I am open to practical suggestions to improve the situation and make it happen soon.

2. Replacing requests goes surely to an interesting direction. I am personally a fan of dropping dependencies and relying on the builtins so, in theory, why not? I can tell you only what I know of the current status of the requests usage and I am not entirely aware of how much we use rely on requests rather than http. Therefore, even considering that possibility is really hard for me now. Maybe it would be interesting to gather some data about the functions called and see how easy it would be. Given this data we could plan, but I am afraid it won't be near future.