wlav
FileExistsError: File already exists: ./site-packages/cppyy_backend/lib/libcppyy_backend.so
I try to make cppyy working with bazel and run into an issue looking exactly as https://github.com/bazelbuild/rules_python/issues/1659. In this comment they identified that this issue seems to be an issue of the upstream repo (cppyy or cppyy-backend in this case)
https://github.com/ipython-contrib/jupyter_contrib_nbextensions/pull/1612 and https://github.com/aws/aws-elastic-beanstalk-cli/pull/469 is how other projects fix this. However, I could not find this in your setup.py. Any help guiding me to the right place is appreciated.
I understand neither the problem, nor the proposed solution, but at issue is likely that the backend is split into two PyPI packages, a large one containing Cling and a small one containing just the wrapper. The latter installs libcppyy_backend.so in a directory of the former, which probably violates a bunch of rules. The original idea/hope was that the large package would change infrequently, with most of the work happening in the wrapper, thus simplifying release turnaround.
Anyway, there are 2 setup.py files involved:
https://github.com/wlav/cppyy-backend/blob/master/cling/setup.py
https://github.com/wlav/cppyy-backend/blob/master/clingwrapper/setup.py
and neither has a scripts option.
Again, I have no idea how bazel works, what the error is precisely, or what the intend is here, but if this is a matter of repackaging, then the best thing to do is to combine these two PyPI packages into a single bazel package, thus side-stepping the problem.
Assuming combining PyPI packages would fix the problems with Bazel builds, would you accept a PR in that direction? Do you foresee any problems taking that approach?
Yes, upstream has also been asking for a cleanup. There could be a top-level setup.py to combine the two (both packages are sitting in the same repo already; upstream even wants to have a single repo for all packages involved, but there would still be a use for 3 PyPI packages b/c of PyPy, but also b/c the backend is conveniently Python-agnostic). With an extra toplevel setup.py, both choices could live side by side to understand the implications. I don't think there are individual users of cppyy-cling out there, but several exist for the cppyy-backend + cppyy-cling combo.
@hofbi This might be unrelated but I ran into the same issue when trying to install cppyy-backend myself and the fix was to revert the changes on clingwrapper/steup.py that happened between v1.5.0 & v1.5.2. More specifically, reverting these: https://github.com/wlav/cppyy-backend/commit/25caf988cef1f2f76705c07b7262f076e8ed0e01 https://github.com/wlav/cppyy-backend/commit/6f074cf193867d18cac6170cc9276d197fe00f44 https://github.com/wlav/cppyy-backend/commit/17ec932086956cbb81a14940a36213df34ab97b3
Essentially it's reverting the changes cause by the commit I mentioned last but mentioned others that are related that too.
