Skip to content
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

Sorting out logging output #231

Open
michaelwood opened this issue Oct 3, 2024 · 1 comment
Open

Sorting out logging output #231

michaelwood opened this issue Oct 3, 2024 · 1 comment
Labels
enhancement New feature or request

Comments

@michaelwood
Copy link
Member

michaelwood commented Oct 3, 2024

Switching to using logging

logging should be a slightly better way to deal with increasing need for output and possibly different locations for the output

Considerations

  • Which errors needs to go to stderr , are they a fault with the application or are they handling something expected but unusual in the data and therefore need to notify the user
  • What level to use for what errors?
  • Does the data run log that is on the dashboard capture both stderr and stdout?
  • We often use call_command and check the output is expected. In call_command the stderr and stdout are local to that instance rather than sys.stderr/stdout
  • What is a useful string format for the logging (do we want it always in a CSV format for example)

django call_command

A wrapper for call_command?

def call_command_with_logging(...):
   stream = TextIO()
   handler = StreamHandler(stream)
   logging.getLogger("").addHandler(handler)
   call_command(...)
   logging.getLogger("").removeHandler(handler)
   return textio

or in each management command we could setup the handler

#...
from django.core.management.base import BaseCommand, CommandError

from logging import StreamHandler

logger = logging.getLogger(__name__)
handler = StreamHandler()
logger.addHandler(handler)


# class Command(BaseCommand) [ this is the context ] :
    def handle(self, *args, **options):

        # By default 'logging' will log to sys.stderr which means that call_command does not capture any output with it's `stderr=<StringIO>` 
        handler.setStream(self.stderr)

#...
@michaelwood michaelwood added the enhancement New feature or request label Oct 3, 2024
@michaelwood
Copy link
Member Author

related to #190

michaelwood added a commit that referenced this issue Oct 3, 2024
* Add funder name, publisher name and always output grant id
* Add test for correct output
* Fix missing output for funder ids
* Move function check_grant_data_tools_compatible into base class
* Rework the logging to use print until we tackle logging issues more
generally due to needing to add test cases with call_command.
see #231
michaelwood added a commit that referenced this issue Oct 3, 2024
* Add funder name, publisher name and always output grant id
* Add test for correct output
* Fix missing output for funder ids
* Move function check_grant_data_tools_compatible into base class
* Rework the logging to use print until we tackle logging issues more
generally due to needing to add test cases with call_command.
see #231
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant