Listening on a specified port
Hi
I'm exploring running Scripted Forms in different situations (inside docker containers or either VMs) and note that there doesn't seem to be a way of specifying the port or ip addresses that the Scripted Forms server listens on.
Being able to set these explicitly is really handy when trying to get some of the other bits of plumbing required to expose http ports in place.
Hi,
When ScriptedForms is installed it also installs itself as a Jupyter notebook server extension. That means you can run jupyter notebook and change the default_url parameter to be /scriptedforms/use/formname.md and then you are also free to change all of the parameters that the notebook server gives you, such as port etc.
Let me know if you have an issues with getting that working.
Ah yes.. that does the trick. eg:
jupyter notebook --NotebookApp.token='' --allow-root --default_url=/scriptedforms/use/scriptedformdemo.md --port=5505
I've been trying to put together a minimal Dockerfile demo to see if I can get it to work with Zeit Now (though I suspect the Docker image file will be too big for the free plan...). Seems to be hitting a js error now, though. Will try to dig into it tomorrow. Setup for now is:
#Dockerfile
FROM python:3.5-slim-stretch
RUN pip3 install scriptedforms
EXPOSE 5505
RUN mkdir -p /var/sf
COPY ./scriptedformdemo.md /var/sf/scriptedformdemo.md
CMD ["/usr/local/bin/jupyter","notebook","--notebook-dir=/var/sf","--NotebookApp.token=''","--allow-root","--default_url=/scriptedforms/use/scriptedformdemo.md","--ip=0.0.0.0","--port=5505"]
And scriptedformdemo.md:
# An example
<section-live>
<variable-string>your_name</variable-string>
```python
print('Hello {}!'.format(your_name))
```
</section-live>
Then:
docker build -t scrf .
docker run -p 8882:5505 scrf
How'd you go with this?
Too big an image for zeit; not had a chance to debug my local Docker thing yet; 3am here already and I'm still behind on yesterday's to do list...
Oops. You got a bit distracted by the sounds of it. Sleep is good for you :).
On Thu., 9 Aug. 2018, 12:12 pm Tony Hirst, [email protected] wrote:
Too big an image for zeit; not had a chance to debug my local Docker thing yet; 3am here already and I'm still behind on yesterday's to do list...
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/SimonBiggs/scriptedforms/issues/278#issuecomment-411614553, or mute the thread https://github.com/notifications/unsubscribe-auth/AGQVewmX-P7nUu4gcJsToXDCHKk7sltbks5uO5p8gaJpZM4Vwnv8 .
@psychemedia I am trying to work out where best to take ScriptedForms for it's deployment story. I am coming up with three distinct paths I could go down. My preference is to only go down one. Given that you have specifically asked questions regarding ports etc I figure you might have an important say on this direction.
Here are my options as I see them:
- Create a JupyterHub server
- Positives
- Users can login, access them from anywhere in the centre
- Python distribution is centrally managed
- Applications are centrally managed
- Negatives
- Set up is not 'plug and play'
- JupyterHub runs on Linux, paths will all display in Linux format by default which may confuse users
- Positives
- Create an Electron App viewer
- Positives
- Becomes a desktop app that is comfortable for users
- Users can set `.form.md` files on their machine to open with this electron app
- All data is local, simpler for users
- Could be made to be plug and play
- Could potentially provide a method for people to bundle forms and a Python distribution with the Electron App viewer making a little portable App framework
- Negatives
- No longer centralised
- Need to have something on every device for it to work
- Will no longer be able to target devices like phones for simple forms served over the intranet
- Positives
- Use pyodide and jyve (https://github.com/deathbeds/jyve/pull/27) to make this completely web based using web assembly
- Positives
- This would be serverless
- Python would run within the users browser
- Could be used to make 'static' pages online for documentation etc
- Negatives
- Difficult to access local files
- Difficult to save
- Difficult to use networking libraries
- Not many python libraries have been ported to wasm for use in pyodide yet
- Positives
Do you happen to have any preferences from the above?
@SimonBiggs Thanks for soliciting a comment...
One of my use cases is distance education, which means we essentially run a BYOD policy when it comes to students. We can't generally guarantee either the O/S or the network quality, although the assumption is if someone runs a platform they can't install desktop packages onto (eg a Chromebook or a tablet), they will have a network connection; and if they have a weak network connection, they'll probably have a computer that works offline and onto which we may be able to get them to install some software (though not always; e.g. work computer and no admin permissions; or running WIndows XP still... ;-).
My preference is for services that run through a browser, and that can be run locally or remotely. Something like RStudio/Shiny manages this well.
So a pure electron app for desktop seems limiting, if you can't also run the same application accessed from a remote server.
Another of my use cases, perhaps more relevant to ScriptedForms, is publishing quick demos or services. datasette is a great example in this respect. It allows you to launch a local server, or bundle everything up as a docker container that can be published on zeit.now, heroku etc.. (There are some issues lately w/ a change to Zeit's defaults.)
Datasette Publish (review) goes a step further, allowing you to upload csv files to a datasette environment and then publish them to your own zeit account. I could imagine a Scripted Forms equivalent where users upload md+datafiles and publish therefrom. (Again, zeit changes may break this.)
In my mind's eye, I can imagine ScriptedForms as a complement to datasette, though ScriptedForms has a heavier requirement in the form of the Jupyter requirement. However, things like ThebeLab or Juniper get round that by making use of Binder backends. There's also nbinteract, but I haven't had a chance to play with that yet and don't completely grok what can be done with it. I think this textbook (repo) uses nbinteract (see also this review fragment I posted on interactive textbooks).