Repository for docs and issues. If you need help, please file an issue here. Public conversations are better for open source projects than private email.
We'd rather not write and maintain all of this shared code in both JavaScript and Python.
So I looked into methods we can use to translate Python into Javascript and then expose this library as both Python and Javascript packages.
I found a few options but 3 main ones.
pyjs formerly known as pyjamas. It is an older project. It seems like it had greater support for Python 2 and only supports a subset of Python 3. No commits on GH since 9 years ago.
brython aka 'browser python'. It is the more popular option (6.2k starts on GH), but I don't think the intended workflow fits our use case. Rather than a static Python -> JS compiler, it more like a JIT compiler/interpreter that runs in the browser, compiling Python to JS at runtime. Supposedly, they take this approach because the compiled JS ends up being extremely large (like 100x the size of the python source) and this makes bundle sizes too large to be practical.
Transcrypt a newer option, established but not as popular (2.8k stars on GH). Last release 1 year ago supporting Python 3.9. Supports precompiling, so we could expose separate JS and Python packages. The generated JS needs a built-in "Transcrypt runtime" which is about 40kb. But from that point on, I think it's about 1:1 for python source size to output JS size.
I think Transcrypt is the closest to what we want. It is stable for Python 3.9. My only reservation is that if the project fizzles out, e-mission-common could be stuck on Python 3.9 and not able to upgrade.
But that probably wouldn't be the end of the world - we could switch to a new translator at a later point in time because the Python source will still be valid Python regardless of what translator we are using.
So I set up e-mission-common with Transcrypt.
For the purpose of testing changes locally, I have included it in e-mission-phone as a local dependency on my filesystem:
When the first version of e-mission-common is done, we can change the local file reference to a git URL reference. Or we could actually publish it to the npm registry.
As for Python I am not entirely sure how the dependencies work in conda. But I'd imagine there should be a way to add a git URL as a dependency. If not we might need to publish it to PyPI.
We would like to be able to share code between e-mission-server, e-mission-phone, em-public-dashboard, and op-admin-dashboard.
I set up a repo for this purpose:
We'd rather not write and maintain all of this shared code in both JavaScript and Python. So I looked into methods we can use to translate Python into Javascript and then expose this library as both Python and Javascript packages.
I found a few options but 3 main ones.
pyjs
formerly known aspyjamas
. It is an older project. It seems like it had greater support for Python 2 and only supports a subset of Python 3. No commits on GH since 9 years ago.brython
aka 'browser python'. It is the more popular option (6.2k starts on GH), but I don't think the intended workflow fits our use case. Rather than a static Python -> JS compiler, it more like a JIT compiler/interpreter that runs in the browser, compiling Python to JS at runtime. Supposedly, they take this approach because the compiled JS ends up being extremely large (like 100x the size of the python source) and this makes bundle sizes too large to be practical.Transcrypt
a newer option, established but not as popular (2.8k stars on GH). Last release 1 year ago supporting Python 3.9. Supports precompiling, so we could expose separate JS and Python packages. The generated JS needs a built-in "Transcrypt runtime" which is about 40kb. But from that point on, I think it's about 1:1 for python source size to output JS size.I think Transcrypt is the closest to what we want. It is stable for Python 3.9. My only reservation is that if the project fizzles out,
e-mission-common
could be stuck on Python 3.9 and not able to upgrade. But that probably wouldn't be the end of the world - we could switch to a new translator at a later point in time because the Python source will still be valid Python regardless of what translator we are using.So I set up
e-mission-common
with Transcrypt.For the purpose of testing changes locally, I have included it in
e-mission-phone
as a local dependency on my filesystem:When the first version of
e-mission-common
is done, we can change the local file reference to a git URL reference. Or we could actually publish it to thenpm
registry.As for Python I am not entirely sure how the dependencies work in
conda
. But I'd imagine there should be a way to add a git URL as a dependency. If not we might need to publish it to PyPI.