C extension modules in 'deps' is not yet supported about subpar HOT 4 OPEN

No particular roadmap or timeline, unfortunately. I understand that the Bazel team does have an intent to officially support Python extensions, but probably not for a while.

from subpar.

With #52, extension modules can be manually extracted. Now I "just" need to wire up some more metadata and plumb it through to the skylark code.

from subpar.

With #65, one can specify py_binary(... zip_safe=False, ...) to cause shared libraries (and everything else) to be extracted to a temporary directory on when the par file is run. The Python sys.path is also updated to enable importing.

There is still no py_extension rule, and depending on external packages is still difficult.

from subpar.

Hi @duggelz ,

Thanks for the nice follow-ups on this thread over the years. I have pretty strong interest in using par_binary() with C extensions (all built with Bazel).

What exactly is the goal of this thread when we are talking about? Is it to support

• a thin path to enable experts in Bazel and CPython get to use C-extensions in python,
• a moderate solution so that the developers familiar with python packaging may use it, or
• a one-stop solution to make it easy to any developer to create C-extensions in python?

Also, what exactly is difficult for enabling depending on external packages? Is it

• too many potential use cases that are hard to exhaustively enumerate,
• use cases with conflicting design goals (and perhaps implementations guidelines),
• hard to migrate a meaningful amount of existing the C-extension packages, or
• lack of general interest from the community?

from subpar.