search

wlav / cppyy

Other
405 stars 42 forks source link

FileExistsError: File already exists: ./site-packages/cppyy_backend/lib/libcppyy_backend.so #266

Open hofbi opened 2 weeks ago

hofbi commented 2 weeks ago

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.

wlav commented 2 weeks ago

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.

matthew-limbinar commented 2 weeks ago

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?

wlav commented 2 weeks ago

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.