Closed walking-octopus closed 1 month ago
I have recently tried to create a container, although more for personal use, feel free to take inspiration here. For my use case, deploying on a server and behind a reverse proxy, I had some problems with all the different ports and hardcoded protocols, but I guess it is more intended for desktop use with electron. Cool project nonetheless :+1:
I have recently tried to create a container, although more for personal use, feel free to take inspiration here. For my use case, deploying on a server and behind a reverse proxy, I had some problems with all the different ports and hardcoded protocols, but I guess it is more intended for desktop use with electron. Cool project nonetheless π
Awesome! Thank you, @yloose β€οΈ We will test you solution and will fix bugs coming from the navigation and etc. The idea with TLS is really inventive ;) @KirillBelovTest had many attempts to implement TLS on the level of TCP server, but faced some serious difficulties. We were actually thinking to hook up an external library for that.
Anyway we should consider to make changes to the main repo in order to make such tricks with TLS easier.
PS: You are right, most people are using it as Desktop app, which moved our attention away from the web-version. But since it is now quite frequently requested, we reconsider that.
We shall include your repo to the main page (README.md).
That sounds great :+1: please let me know if you need any help regarding the container.
Anyway we should consider to make changes to the main repo in order to make such tricks with TLS easier.
That would be nice, I just took a quick look and something like this would probably be enough, but I need to do some more testing.
That sounds great π please let me know if you need any help regarding the container.
Anyway we should consider to make changes to the main repo in order to make such tricks with TLS easier.
That would be nice, I just took a quick look and something like this would probably be enough, but I need to do some more testing.
Great and simple idea :)
Merged to dev
branch, I will test and if everything is fine I will push it to main
branch. Also this I changed accordingly
Checked. Works fine. Merged to main
Very nice, works great!
If the container is tested some more, I've looked into integrating it into to the main repo using github actions so it gets build automatically on every release or manually against any branch. Cf. my fork. That way users don't have to build the container manually and can just pull it from ghcr.io.
If the container is tested some more, I've looked into integrating it into to the main repo using github actions so it gets build automatically on every release or manually against any branch. Cf. my fork. That way users don't have to build the container manually and can just pull it from ghcr.io.
I have a little experience with docker, but managed to start it using your fork :) I believe the biggest issues for a user might be licensing. I don't know, but is there any solution to start it in the interactive mode and activate WL from cmd on the first run?
Tried this
sudo docker run -it -v WolframLicensing:/Licensing -v ~/Documents/wljs:/workspace -e PUID=2000 -e PGID=2000 -p 4000:4000 -p 4001:4001 -p 4002:4002 -p 4003:4003 --name wljs ghcr.io/yloose/wolfram-js-frontend:latest
No license file available!
I have used the same mathpass file the whole time that I have once generated with wolframscript -activate
. When I looked into building the container earlier this year, I had some really annoying problems with the whole account stuff. I could only generate two licenses per account and couldn't reset them...
Anyways after trying now it all worked pretty good. I have updated the container and README. You can enter the credentials interactively or pass them via environment variables. This container should be up to date: ghcr.io/yloose/wolfram-js-frontend:main
.
Thank you. It worked for me
I see some issues with navigating. However, this is an easy fix. By the way, I don't know if this is a feature of naming, but it only worked if change for each command mentioned in README latest
to main
.
I believe I also need to add privilege for read/write access check within the frontend. So that a red message pop up, if a folder does not have right groupid.
UPD: pushed changes to dev
Great! Yeah so the way it is setup is that Github automatically builds a docker image on release with the tag <repo>:<release_version>
e.g. ghcr.io/yloose/wolfram-js-frontend:v1.1.0
. The newest release is also tagged with <repo>:latest
. That way when using latest the user always gets the latest stable release. You can however generate an image directly from a branch, in this case main
, which is then tagged with the branch name e.g. <repo>:main
. The changes with the authentication where only on the main branch and not in any release, thats why you needed to use main
.
I believe I also need to add privilege for read/write access check within the frontend. So that a red message pop up, if a folder does not have right groupid.
That is a good idea, I also thought of maybe adding a way to restrict the navigation: For example a --root-dir
flag, where a directory could be set which cannot be left in the UI, i.d. the user cannot navigate upwards anymore. Because in the container it does not make sense to leave to working directory. Though I don't know how hard that would be to implement, just an idea.
I believe I also need to add privilege for read/write access check within the frontend. So that a red message pop up, if a folder does not have right groupid.
That is a good idea, I also thought of maybe adding a way to restrict the navigation: For example a
--root-dir
flag, where a directory could be set which cannot be left in the UI, i.d. the user cannot navigate upwards anymore. Because in the container it does not make sense to leave to working directory. Though I don't know how hard that would be to implement, just an idea.
I did exactly this. A button should just disappear if a user is already in a working directory provided by folder
argument you used already.
I suggest moving the Activation
section up since this is the first step for new users. Additionally, add a small tutorial section for first-time users. For example: (probably its an overkill :D )
docker
or podman
on your machine if you do not have them already.docker pull ghcr.io/yloose/wolfram-js-frontend:latest
docker run -it -v WolframLicensing:/Licensing -v ~/Documents/wljs:/workspace -e PUID=2000 -e PGID=2000 -p 4000:4000 -p 4001:4001 -p 4002:4002 -p 4003:4003 --name wljs ghcr.io/yloose/wolfram-js-frontend:latest
~/Documents/wljs
folder on your local machine. Set it to ..........Get your license
instructions. Register on the next page and acquire the license (it is free). A confirmation message will be sent to your email address. Please follow the link received by email.Open your browser at http://...
appears.Open a web browser and go to:
http://127.0.0.1:4000
or, if you are running it on a remote server:
http://<public-ip>:4000
I did some refactoring using your example, let me know what you think :smile: (Link). I also changed the example docker run
command so the uid and gid of the user inside the container is the same as the user starting the container. This way some of the manual permission checking at step 4 should hopefully be resolved.
I did some refactoring using your example, let me know what you think π (Link). I also changed the example
docker run
command so the uid and gid of the user inside the container is the same as the user starting the container. This way some of the manual permission checking at step 4 should hopefully be resolved.
Awesome! I think itβs time to open pull request :)
Wolfram Engine can officially ship as a Docker image, which is preferable in many environments.
It would probably be trivial to create a Docker image for this repo that depends on Wolfram Engine, making it much easier to deploy.