ISISComputingGroup / lewis-ess

Let's write intricate simulators!
GNU General Public License v3.0
21 stars 19 forks source link

Yet another way to run Lewis #270

Closed MichaelWedel closed 3 years ago

MichaelWedel commented 6 years ago

In the most recent episode of the Python bytes podcast they talked about pex, which I found pretty interesting. Essentially it's another way to distribute Python packages as a single file. It is especially suited for packages like Lewis, which provide an "executable". Usage is really simple:

(some-virtualenv)$ pip install pex requests
(some-virtualenv)$ pex -v -c lewis -o lewis.pex lewis

This will download Lewis and all its dependencies from PyPI and put them into one executable file. Building took a few seconds on my machine, due to the fact that pyzmq had to be compiled. I'm not sure if this would work with EPICS, but it might. The resulting lewis.pex file is less than 4 MB in size, which is even smaller than the docker images. The file can be used like the usual lewis executable:

(some-virtualenv)$ deactivate
$ ./lewis.pex -k lewis.examples simple_device -p "stream: {bind_address: localhost}"

A Python interepreter is still required, and if I understood correctly, the file is system dependent (e.g. a pex-file built on Linux won't work on other systems). From my (few and limited) experiments it seems that at least the preparing the file like this won't import modules from "outside", so I assume any extra device modules would have to be part of that bundle.

Anyway, I just wanted to share, because as I mentioned above, I found this interesting. It seems to me like a middle ground between using docker and installing Lewis as a Python package in the system path. If it turns out to be working with "external device modules", this could be a nice way to deploy specific devices.

Do you think it would be worth mentioning this in the docs? In that case I'd certainly volunteer :)

MikeHart85 commented 6 years ago

Looks interesting, I'll have to try it out!

A section in the documentation mentioning this as an option wouldn't hurt.

But I don't think it should be front and center, we already start the documentation with many sections on different ways to start Lewis. This is probably not so good for a new user trying to figure out how to run Lewis and just see it doing something.

In general, I think we should revise the "beginning" of the documentation to be more friendly to new users. Probably just present one way of running (I'm leaning towards PIP), ignore complicated optional requirements (like EPICS), and just provide specific examples of use cases with command line samples so they only need to copy-paste to run. Things like "run up an example motor like this", "then connect to it with Telnet like this", "here are some commands it understands, see how it responds", "now also connect to it using lewis-control", "here are some things you can do there (see how it also changes in telnet)", "lets try the same using the Python API", ...

These sections should be short and don't need to show everything possible... just a sample of what could be done so the new user can get a picture of what Lewis does, and get comfortable with using it. Additional details on each of the features highlighted, as well as things like alternative ways of running Lewis, how to get it to work with EPICS, etc... should probably be separate sections that come later I think.

Anyway, this is starting to sound like a separate issue!

MichaelWedel commented 6 years ago

It all goes back to #263 I suppose, there really seems to be the need for a "Quickstart" section.