This is not a valid check.source andtarget could be on different drives (on Windows), in which caserelative_to will fail with aValueError.

The logic here seems backwards to me. Rather than trying to replicate the filtering done in the archive writing loop, we should be calculating files_to_add more precisely, based on the filter. That wouldn't fix the problem oftarget being on a different drive, though - there's a fundamental problem with the whole idea here, asfilter is defined to work on thearcname of the source file, andtarget may not even have a definedarcname, because logically it isn't a source file.

Ultimately, the correct answer here is what I've said elsewhere -don't put your output file in the directory you're creating the zipapp from. That's a much more straightforward approach than trying to exclude it using a filter.

Thanks for taking the time with this! You are right of course, that check is wrong and can fail even within a single drive I believe. I've rewritten the code to filter files_to_add right away and then just use your original target check.

I can appreciate your sentiment about not writing the output file to the source directory, but I would prefer not to mess with my build system and I still think this change is for the better. I use the filter as a whitelist, precisely because I know that I can't trust the source directory to always be clean. I think it's pretty risk free™.

Hm, thinking some more about it, I'm not sure I see how the relative_to check could fail. It's only performed after we've confirmed that target is equal to one of the paths inside source. But there could be intricacies to the Path class that I'm missing, and I think the new code is a cleaner way of doing this either way.

The comprehension doesn't add to readability, IMO. I suggest something more like:

files_to_add = []for file in sorted(source.rglob("*")):    relative_name = file.relative_to(source)    if filter is None or filter(relative_name):        files_to_add.append((file, relative_name))

I can do away with the comprehension, but building files_to_add as a list of tuples makes it more difficult to search for target in it. A simpletarget in files_to_add will no longer work.
One option is to again use a dictionary for files_to_add. Another is to do the check for target as part of this loop, like this:

files_to_add = []for file in sorted(source.rglob("*")):    relative_name = file.relative_to(source)    if filter is None or filter(relative_name):        if file == target:            raise ZipAppError(...)        files_to_add.append((file, relative_name))

I have no strong opinion. Doing the target check separately astarget in files_to_add is more idiomatic but doing it as part of the loop (as above) is probably a tiny bit more efficient.

Good point. I have no particular opinion between using a dictionary or checking in the loop - do whatever you prefer. But let's use an explicit loop, readability is important.

Ok, I went with the dictionary. It occurred to me that when files_to_add is a dictionary, thetarget in files_to_add check should be basically free, and more importantly, this means I don't have to split the exception message string over two lines. :)

I disagree strongly with this news item, as it suggests that writing the target into the source directory is intended usage.

Maybe

The zipapp module now applies the filter when creating the list of files to add, rather than waiting until the file is being added to the archive

Sure. I wanted to get a bit of rationale in there, but I agree that it could come off as a recommendation, and it got long-winded too. I'll change it.

Unintended blank line?

Yes, will fix!

Thanks, copy/paste error!