Add method to LogCaptureFixture to get records by a given logger name

[debugduck]

I saw #9110 and noticed that there hadn't really been any discussion around it so I thought I'd try it out. I created this PR as a draft because I want to include a test but first wanted to get some feedback on the approach.

There were a couple of solutions discussed in the issue, including being able to only capture logs from a specified logger, but I chose to simply add a method get_records_by_logger with a few considerations:

• There is already a get_records method and it seemed that a similar method that filters on logger name instead of test phase would fit in with the existing structure (although I'm not sure if others would disagree or feel that we wouldn't want to clutter the LogCaptureFixture class with convenience methods?)
• If we chose the alternative approach to only capture logs from a specific logger, would we then lose that information? It felt better to me to filter the existing records to what we need rather than only capture specific records.
• The original issue wanted this addition as a convenience method, so it seemed to me that a get_records_by_logger method would be the most straightforward and easy to use solution

[kasium]

@debugduck thanks for the PR. From my point of view, this is everything I need. Of course, let's see what others are thinking

[andrewdotn]

Looks fine to me …

[andrewdotn]

You‘ll need to add a changelog file as described in step 5 of https://github.com/pytest-dev/pytest/blob/main/CONTRIBUTING.rst#short-version

[kasium]

@debugduck can you please add the changelog or can I support you somehow?

[nicoddemus]

Hi @debugduck,

Thanks a lot for the contribution, we appreciate it!

feel that we wouldn't want to clutter the LogCaptureFixture class with convenience methods?

However I lean towards this, as there's already a one line solution in Python that can accomplish the same, being also more flexible (you can get loggers that start with a certain prefix, include the level in the query, etc). I don't think this is common enough that everybody uses this frequently, which would justify adding it as a convenience method to the core. If this is done a lot in a given project, this can be easily put into a helper function.

However let's see how others feel about it.

[twmr]

What about adding an optional logger parameter to get_records instead of introducing a new method in the LogCaptureFixture class?

[twmr]

I don't understand why you need to use pytester in your test. I think it suffices if you only uses the caplog fixture and not the pytester fixture.

[bluetech]

This PR adds a method to retrieve records by logger name. I think a more common use case it to retrieve by log level. And there also other record attributes the user might want to filter by. Adding a separate method for each use case is not very scalable, so we'll probably want a single method with kwargs for various filters. But then it seems more complex and less flexible than just having the user filter caplog.records directly with a list comprehension. So I tend to agree with @nicoddemus - it's not worth it.

@Thisch

What about adding an optional logger parameter to get_records instead of introducing a new method in the LogCaptureFixture class?

get_records currently filters by the test phase (setup/call/teardown) and uses a separate internal mechanism to obtain the records. Though that shouldn't necessarily prevent allowing when to be None, and use self.handler.records then.

[twmr]

I also agree that we should close this PR

[nicoddemus]

Thanks everyone.

Thanks again @debugduck for the contribution (love the handle name btw)