Nice! I like this. My current thinking is that I prefer this to your alternative idea because I want to avoid changing the user API unnecessarily and I think the use cases for examining packets as binary data only are mostly going to use an additional abstraction layer rather than users calling the packet_generator directly. I think we should leave it public in case someone decides they want to use it in a custom way but I think packet_generator is mostly going to be used through CLI tools.

I think we could support backwards compatibility with the definition.packet_generator() if we want and use that to redirect to the primary packet generator location with a deprecation if we want too.

        definition = None if ccsds_headers_only else self
        for packet in packets.packet_generator(binary_data,
                                               definition=definition,
                                               buffer_read_size_bytes=buffer_read_size_bytes,
                                               show_progress=show_progress,
                                               skip_header_bytes=skip_header_bytes):
            yield packet

The benefit I see is that there is only one generator that someone would have to know about and they could bring their own definition(s) to it. I'm envisioning that we have multiple XTCE definitions hanging around on a mission and don't want to potentially have to know which definition I need to use, so create a list and iterate through it. (Is there a way to combine XTCE definitions internally for us to consider as well?)

definitions = [XtcePacketDefinition(file) for file in list_of_files]

Currently I think we'd have to do this:

for definition in definitions:
    generator = getattr(definition, "packet_generator")
    for packet in generator(data):
        # Do something

With a single entry-point we could write it like this:

for definition in definitions:
    for packet in packets.packet_generator(data, definition=definition):
        # Do something

Thinking towards the future, we could even potentially support passing in multiple definitions with this approach and doing the iteration for a user:

for packet in packets.packet_generator(data, definition=definitions):
    # Do something

I pushed two new commits. One somewhat unrelated but was easier to clean it up here by removing the **parse_kwargs that appear unused now. I can move that to a separate PR if desired. The final commit moves all of the packet parsing logic into the packets.py file now, but leaves the definition.packet_generator() around and just yields from the main generator passing through the proper arguments. Let me know your thoughts on those and I can break them off into separate PRs if you'd prefer to keep this just on adding the new functionality for now.