Open vojtamolda opened 2 years ago
I have a few ideas how to fix the problem but none of them seems to be ideal:
Add PythonKit as a regular dependency. This makes the project a little bit heavier for all users. Everyone would need to download and build it although they don't need the notebook functionality nor Python.
Introduce a new preprocessor variable JUPYTER_SUPPORT
(suggestions for a better name are welcome ;) and replace the guard with
#if JUPYTER_SUPPORT
This breaks the auto-magically working support for Colab/Jupyter notebooks because users would now have to pass a -D JUPYTER_SUPORT
flag.
Detect Jupyter via an environmental variable (ProcessInfo.processInfo.environment
dict) at runtime. I'm not 100% sure if this is possible so it needs proper investigation. It isn't clear what to do if the variable isn't defined. The Figure
class would have .show()
and .display()
methods available everywhere without a clear distinction to a new user.
Drop the support for Colab/Jupyter altogether. There seems to be some effort to revive S4TF orchestrated by Philip Turner. So maybe there are better days ahead...
When Plotly.swift is used in a larger project, that also depends on PythonKit, build fails with unresolved symbols.
Currently, the support for Jupyter notebooks is implement in a slightly hack-ish way
The
#if
guard is placed around aFigure
extension that implements the.display()
method. This works auto-magically without any user intervention in Google Colab/Jupyter Notebooks, because they rely on Python to communicate with the Jupyter kernel and make it available for import by default.However, when Plotly.swift is used in a larger project, that also happens to use PythonKit, the package fails to build. Since PythonKit is available for import the
#if
guard evaluates to true. The SwitPM build, though, doesn't see any formally declared dependency on PythonKit inPackage.swift
manifest and therefore doesn't link against it. This causes the unresolved symbols linking error.