DEV Community

Discussion on: Why Starting a Fresh EC2 Instance and Running Python with Meadowrun Took Over a Minute

Collapse
 
kurt2001 profile image
Kurt • Edited

Thanks John. I've had good experience with Eliot, the only thing I would say is it does affect import times a bit, as it also pulls in pyrsistent and a few other dependencies. So I've been reluctant to actually merge the Eliot code changes into main so far. We could address that by abstracting it behind an optional module, but haven't put in the work so far.

Collapse
 
rouilj profile image
John P. Rouillard

Thanks for the info Kurt. I also have a few other issues:

  1. The Roundup codebase I am working with runs under both python 2 and 3.
  2. There is a fork of Eliot that runs under python 2 used by tahoe-lafs. that might work.
  3. I don't want to require Eliot to be installed to run Roundup. Along with #3, I would like a mock that does nothing that I can vendor into the codebase if import eliot fails.

Also #3 is required to allow the user to disable logging. This is required for performance if Roundup is deployed to a raspberry-pi for example. Setting the log level to Error with native python logging allows the user to remove the performance issues without code base changes.

I may be able to wrap eliot calls in if blocks but ....

Thread Thread
 
kurt2001 profile image
Kurt

Re: 3 I had the same idea, I don't want Eliot as a runtime dependency of meadowrun (or at the very least only as an optional one).

I started by making a facade to Eliot in an optional_eliot.py module, and mocking the calls if the import fails: github.com/kurtschelfthout/meadowr...

Please be advised that that file is only a very rough sketch - the actual Eliot calls work but the mock calls definitely don't. I think that approach would be nicer than trying to wrap every eliot call in an if, with similar small overheads if Eliot is not present.