You could rewrite the argument list as:

def setUp(self, archive_name, *, start_path, filename=None,
          resources_path='resources', prefix_tmp_folder_name=''):

It makes start_path a keyword-only but mandatory parameter.

This way you don't need to check start_path.

You can drop the v argument. It shouldn't be an issue unless the test case calling it has a huge file list.

You might want to add (releases, expected_releases) as third argument to provide a helpful error message in case it fails.

same

same

What does this comment mean?

\m/

I don't have much else to say than the default message... :)

No idea what i meant, removing!

ah, that was what i meant... the key is the 'type'!

Clearly indicating in the docstring the behavior when filename is None would be useful.

I would have written "sent to storage" here

I would have used "col.append(o)" here

s/variable/variables/

Yes.

Is the following clear enough?

filename (str/None): Name of the filename/folder once the
    archive is uncompressed. When the filename is not
    provided, the archive name is used as a derivative. This
    is used both for the self.repo_url and
    self.destination_path computation (this one only when
    provided)

sold!

Yes, that's pretty clear ! :-)

lgtm. Optional[str] instead of str/None if you want to write it in a PEP484-like way.

Thank you!

What's the point of having this list here? it's going to be a pain to maintain (and hence will probably get out of date soon).

I suggest to remove the list of rev deps alltogether.

The point is people going through our loaders' docs could start by that one...
Alphabetically, it's the first.

Historically, i started that listing as a todo list.
When our loaders did not share the core's behavior.

Ok for removing it if it's not considered interesting enough.

I don't it's uninteresting. I'm just saying it's gonna be a pain to maintain and will become out of date quickly.
Reverse dependency information is indeed useful, but we already have a place where it is stored (and generated automatically).
I hear your point about not fooling people into thinking this is a real load; but I think the header to the core loader that I've recently added (which reads "Low-level loading utilities and helpers used by other loaders.") should be enough to dispel that risk. Feel free to use it at the beginning of the README if you see fit.

It's a deal!
Thanks.

I'd rather we fix this now then (the part you mentioned about pytest can be dealt with without impact, but this is not easily the case here). I'd like to settle on this once and for all and no longer have to worry about those ever again.

I can think of a middle-ground to reduce the impact on the other loader's tests though!

Note: The prefixed names are here because the internal loader-core uses those without all_ already.
They must have been badly named in the first place. As they are internal they should have been probably named with __ in the first place.

I'll commit later this part that cleans up this.