-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
gearbox serve: LazyWriter problem #26
Comments
In this case I think that probably we could easily add the If you are willing to submit a PR that adds the |
I don't know which daemonization cases could be relevant. I would expect the daemonization (like systemd) to capture stdout / stderr, and it would be very wrong to use And when using I thus suggest just removing
(barely worth creating a PR for this) |
By daemonization I actually meant the |
Ok. I don't see ( FWIW, http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/278731 is also dead ) But AFAICS, there shouldn't be a problem with |
gearbox serve patches stdout/stderr to be an object of class LazyWriter, which only opens the file when something is written. Is this only to avoid an empty log file in case an application never actually writes anything?
In the Kallithea project, a problem was reported [1] which is actually not related to Kallithea itself but by the interaction between Mercurial code and gearbox Lazywriter. Mercurial wants to access the 'buffer' property of stdout/stderr, but Lazywriter does not implement it.
In order to work around it from Kallithea, we have to do something like [2] which is not very nice.
A possible alternative is that LazyWriter actually forwards any attribute access it doesn't know about to the real file object (but in this case it should actually open the file).
Another alternative is to just stop using LazyWriter. If the only goal is to not create an empty log file when the app happens to be silent, then I don't consider it as having much value. Many UNIX applications that accept a log file path as argument will create the file regardless of output.
Maybe other solutions exist too.
[1] https://bitbucket.org/conservancy/kallithea/issues/371
[2] https://kallithea-scm.org/repos/kallithea-incoming/changeset/ba656cdb88eae618beb3d6b83b2c14584b9233d8
The text was updated successfully, but these errors were encountered: