I think it would be quite useful to implement SP wide logging though the logging libary. Right now, we only have printing to console using the print() function, but implementation of logging these things though the logging module would take everything multiple steps further.
If you don't know about the logging module, you can find the docs here:
http://docs.python.org/py3k/library/logging.html
http://docs.python.org/py3k/library/logging.config.html
http://docs.python.org/py3k/library/logging.handlers.html
I think this would a great way to provide logging besides the normal server log. Since scripts can access the sp.py or the logging module, they could their own logging handlers - for example, a custom addon may specific logging all SP events with a certain level to a file or even send those logs over the network to a server - for example, this could be useful for admins wanting to monitor what is going on their server (-- module loads, errors etc).
Also, this would allow for the addition of log levels for the particular messages sent to the server console. Again, this would be helpful since people can set the logging level to filter out messages you don't want or want to see in the server console (for example, you may not want to see errors or debugging info in console to improve usability [everyone who tried to do something in SRCDS when the console is getting spammed knows what I means :P], but still want them logged to the harddrive)
It also allows the implementation for module level logging, so modules can also use their own logging handlers/formats. If they don't, they just use the SP defaults - this way printing to console for example can be done in a very convinient and consistent way; for example, if we suddenly want to change the format from [SP] msg to [{time}] [SP] msg that would require replacing the print functions [and essentially writing sp's own logger, though in a more simple form].
This may have some performance impact, but I assume that most logging messages are not occuring on a tick lister so performance impacts should be neligble [also string formatting generally only occurs wtih the logging function if the message is valid for the specifid logging level].
Feature proposal: SP-wide logging -- the python logging module
We will have to discuss this further internally at a later time. If you wish to work on an API for this on your own, and submit it, we have no issue with that. That would also help us get a better feel for whether or not it is something we would wish to implement. If we decide one way or the other in the meantime, we will be sure to let you know.
I will comment on one point at this time, though:
Having logging levels to the server console has already been discussed. We intend to hook Developer Messaging and utilize the -deveoper command line parameter for this purpose.
Satoon
I will comment on one point at this time, though:
Having logging levels to the server console has already been discussed. We intend to hook Developer Messaging and utilize the -deveoper command line parameter for this purpose.
Satoon
Sounds good. Post either here or in the Module/Package Submissions forum when you have something working.
Thanks,
Satoon
Thanks,
Satoon
Done. Zip including new/changed files: [ATTACH]38[/ATTACH]
If you have any questions let me know.
Notes:
file-logging is just an example how addons could extend the logging system [I suppose a decent addon would be better!]
I added a log folder; seems to make sense ( log/source-python/ )
If you have any questions let me know.
Notes:
file-logging is just an example how addons could extend the logging system [I suppose a decent addon would be better!]
I added a log folder; seems to make sense ( log/source-python/ )
- Attachments
-
- sp.zip
- (8.23 KiB) Downloaded 1968 times
I still have not had a lot of time to look into this or had a chance test it out yet, but I have come to the conclusion that I wish for this functionality to be included. The plan, currently, is to use a base settings file (possibly located at ../cfg/source-python/core_settings.ini) that will house basic configurations for Source.Python. One of the sections in the configuration will be for logging, and might look something like:This file will only be parsed when the server is booted. Though, I do intend on possibly adding console commands to set each of these while the server is running. I have moved this to the Module/Package Submission forum, since that forum seems more appropriate for it at this time.
As far as the makeup of the logging module itself, I would basically like to see something like this:
Satoon
Code: Select all
[LOGGING_SETTINGS]
Logging_Level=0
# Available Logging Types:
# Console
# Log File
Logging_Type="Console"As far as the makeup of the logging module itself, I would basically like to see something like this:
- Text is passed to the logger with its logging level
- If the level is greater than the current value of Source.Python's logging level, it simply returns and does nothing
- Otherwise, if the logging type is set to console (we could also use 1/0 for this value instead), the text is printed to the console.
- If logging type is log to file, it logs it to the appropriate file
Satoon
The python module pretty much does all that and more; the good thing is that we can do module-level logging (and also module-based logging levels), so one module can run in debugging mode while the normal SP thing just runs in normal logging mode.
Again one of the good things here is as soon the logging objects are exposed any script can just import the file and add their own logging handler. Python itself comes with about 14 different logging handler that can be used.
But anyway, since I think it makes sense to have some logging setup on init that config file makes sense, so at the very least file and console logging should be included. Though what I see here is that some people may want to extend that functionality, so going with both should work.
Again one of the good things here is as soon the logging objects are exposed any script can just import the file and add their own logging handler. Python itself comes with about 14 different logging handler that can be used.
But anyway, since I think it makes sense to have some logging setup on init that config file makes sense, so at the very least file and console logging should be included. Though what I see here is that some people may want to extend that functionality, so going with both should work.
Should I create a new version of the sp files with the logging included?
The old one probably might have some problems with merging. Mostly it's just replacing prints anyway.
It's just a question of how you want it to be set up; I think some of the normal output should be logged aswell such as addon load/onload, though only by default to console, not to file. With the python thing is not a problem to setup, as the logging level for a handler can be different to the logging level of another one (basically, console should run on a INFO level and file logging for warnings /errors)
The old one probably might have some problems with merging. Mostly it's just replacing prints anyway.
It's just a question of how you want it to be set up; I think some of the normal output should be logged aswell such as addon load/onload, though only by default to console, not to file. With the python thing is not a problem to setup, as the logging level for a handler can be different to the logging level of another one (basically, console should run on a INFO level and file logging for warnings /errors)
As of right now, I am going to put an internal freeze on modifying any of the _libs/addons/ and _libs/events directories, as well as the current functions currently within sp.py. Feel free to modify those any way you wish, as we will not be modifying them ourselves.
The normal output stuff will always be set at level 0, so they should always be logged (whether to console or to file), though, I guess we could make level 0 also always print to console regardless of the log_to_file setting.
I guess my question would be about how you mentioned having some modules log while others do not. How do you propose we go about setting that up so that the logger knows what to log and not to log? I don't want to make this needlessly overly complicated, so if this type of feature is going to cause that to happen, I say we can do without. Having an API to log for scripts, though, is definitely something I would like to look into.
I cannot wait to see what you come up with. Also, please include proper documentation in your script.
Satoon
The normal output stuff will always be set at level 0, so they should always be logged (whether to console or to file), though, I guess we could make level 0 also always print to console regardless of the log_to_file setting.
I guess my question would be about how you mentioned having some modules log while others do not. How do you propose we go about setting that up so that the logger knows what to log and not to log? I don't want to make this needlessly overly complicated, so if this type of feature is going to cause that to happen, I say we can do without. Having an API to log for scripts, though, is definitely something I would like to look into.
I cannot wait to see what you come up with. Also, please include proper documentation in your script.
Satoon
Based it on the way how it works, it is really easy to implent module based logging. I just made it so that by default, everything gets logged to console. Once the config is made, this can be adjusted accordingly (along with the default levels).
Logging more at the module level can be done by adding a handler with a higher log level or adding a filter to lower level modules.
Note that I did not include file logging so far, (but it just works in a similar way - create a FileHandler object and add it to the logging stuff basically). Also, with the filters cool things could be done,like logging everything but errors to source-python/general.log and exceptions to soruce-python/exceptions.log
Logging more at the module level can be done by adding a handler with a higher log level or adding a filter to lower level modules.
Note that I did not include file logging so far, (but it just works in a similar way - create a FileHandler object and add it to the logging stuff basically). Also, with the filters cool things could be done,like logging everything but errors to source-python/general.log and exceptions to soruce-python/exceptions.log
- Attachments
-
- log.zip
- (5.86 KiB) Downloaded 2094 times
Return to “Module/Package Submissions”
Who is online
Users browsing this forum: No registered users and 1 guest