Tiny nit, I think since this produces a class it's clearer to use the normal class naming rules. I also think it's okay to not mark it as internal, particularly since if someone is using this module like a library... well, we're not making any effort at having that work.

It seems you can specify type hints by defining things this way, which I think is helpful:

from typing import NamedTuple
class ReleaseInfo(NamedTuple):
    fedfind_release: ff_release.Release
    release_number: int   # not sure if this is true, maybe str is fine.
    end_of_life: datetime.datetime   # not sure if this is true, maybe str is fine.

Does this function ever raise UnsupportedComposeError? It seems like it wouldn't, but Python makes it so hard to tell.

If it isn't expected to, it might be better to move it out of the try/except block.

I noted a couple minor things, but nothing that'd stop me from taking it as is if you disagree. This looks like a great improvement, thank you!

Thanks, adjusted both of those. I kept the existing names of the properties for the ReleaseInfo namedtuple, though, I think they're sufficiently verbose while requiring less typing and keeping line lengths short...if you'd really prefer very_long_and_expressive_variable_names I can tweak it again. :D

I don't see a cassette for this test and it's failing trying to connect to localhost:5001 which makes me think some test setup got lost.

oh, I guess I forgot to git add the cassette. fixed.

the plan there is that, once this PR is merged, we change that URL to point to the copy in the repo itself, and retake the cassette. but we can't do that till the PR is merged. catch 22 situation.

Okay. It's not like there's CI to break anyway so...