-
Kirill Smelkov authored
With newer setuptools that is coming via nexedi/slapos!1550 (44.1.1 -> 67.8.0) we will need a fix from setuptools-dso 2.10 to handle `python setup develop` well: Previously with setutools-dso 2.9 and setuptools 67.8.0 built shared libraries were not copied back into the working tree upon develop install which made anything using pygolang to fail as e.g. $ ../bin/gpython Traceback (most recent call last): File ".../../bin/gpython", line 20, in <module> sys.exit(gpython.main()) File ".../pygolang/gpython/__init__.py", line 456, in main pymain(argv, init) File ".../pygolang/gpython/__init__.py", line 223, in pymain init() File ".../pygolang/gpython/__init__.py", line 447, in init import golang File ".../pygolang/golang/__init__.py", line 41, in <module> from golang._gopath import gimport # make gimport available from golang File ".../pygolang/golang/_gopath.py", line 65, in <module> from golang import sync File ".../pygolang/golang/sync.py", line 36, in <module> from golang._sync import \ ImportError: liblibgolang.so.0.1: cannot open shared object file: No such file or directory See https://github.com/mdavidsaver/setuptools_dso/pull/29#issuecomment-1745790761 and https://github.com/mdavidsaver/setuptools_dso/commit/2fdf75f2 for details. P.S. NOTE that changing version of a setup-egg required egg currently does _not_ force a rebuild. In other words pushing this change into testnodes won't make pygolang t o be rebuilt at all. I think this is simply a bug in slapos.buildout to fix. /reported-by @xavier_thompson /cc @jerome, @tomo, @kazuhiko /reviewed-on nexedi/slapos!1585
5eed3c4b