[18:20] <CcxWrk> bzr shell was too fiddly last time I tried to use it. Mercurial actually has fully functional background program for this.
[18:21] <CcxWrk> Or rather, bzr shell really really isn't designed for non-interactive/scripting use.
[18:27] <CcxWrk> https://www.mercurial-scm.org/wiki/CommandServer
[18:32] <CcxWrk> FWIW on POSIX platforms you can just send CWD and stdio file descriptors over unix socket, so it can work pretty seamlessly. I wish there was a generic Python module for that, as the start up time for a lot of software is really bad.
[18:34] <LeoNerd> Yah; it's a common thought. It's basically just "do FastCGI"
[18:34] <LeoNerd> The "Fast" part of FastCGI is really just a UNIX process server system, it has verylittle to do with CGI or webserving or anything else
[18:35] <LeoNerd> Connect to a socket, send initial environment, stream stdin in, stream stdout / stderr back out, accept exit code at the end
[18:37] <CcxWrk> It's a hack ultimately. Workaround for slow startup time. But there is only so much you can do with Python to speed it up.
[18:47] <LeoNerd> It's a nice idea regardless of the language though. It means programs can open database connections, precache things,.. whatever they need..
[19:08] <CcxWrk> Idea is nice, how many edge cases you will run into depends on how you use it. But with shoveling all of env/cwd/stdio into it the rest is pretty much inherent issues of preloading libraries.
[19:20] <CcxWrk> And signals, which also need special handling. Oh well, operating systems are messy. :-]
[19:41] <jelmer> CcxWck: are you sure you're talking about 'bzr shell' and not 'bzr service'?
[19:41] <jelmer> The latter is a background service
[19:42] <jelmer> The former is just a way of not paying for cache load/import time repeatedly