Before we naively expose this behavior, let's ask ourselves what these functions are used for (in pywin32) and determine where is the best place to host them. Setuptools is aiming to be primarily a build backend and not have dependencies on the library (except in setup.py). I see that pywin32 uses two functions, one in setup.py and the other in a test. Moreover, the one use in setup.py has a comment "unclear why we need to check this".

I'd like to first determine what newer_group does, if it's needed to build pywin32, and if so, what purpose it serves. I'd still be tempted to provide it outside setuptools, or limit calls that are exposed here.

let's ask ourselves what these functions are used for (in pywin32) and determine where is the best place to host them. Setuptools is aiming to be primarily a build backend and not have dependencies on the library (except in setup.py).

Sounds sensible to me. I'll do some investigation on pywin32's side and see how much value these utility methods bring it (or dont).

In pywin32 it's used to check if a file should be rebuilt/re-generated. All 3 instances of newer and newer_group seem to simply be a build optimisation.
The one newer in tests could be moved to test utils.
newer_group in setup.py I might have to re-implement to avoid depending on distutils directly.
Exploratory PR here: mhammond/pywin32#2141

[...] determine where is the best place to host them. [...] I'd still be tempted to provide it outside setuptools

I think I get what you're going for here. Either these 4 file-edit-time comparison methods could be moved to their own library, or included as part of an existing file-manipulation one. Where it would belong better than in setuptools. I think it does make sense, I'm not sure where it would belong best though and where to start requesting.

Thanks for the exploration. I do think we want to expose these functions from setuptools.

I did some work in distutils to modernize and clean up the implementations. That should make implementing newer_pairwise_groups much easier.

Before we expose these new public names, I do think we should seriously consider re-naming this module. dep_util doesn't convey very well the purpose. In fact "util" in any module name is usually superfluous. And "dep" doesn't tell me much. I'm thinking "fresh" or "freshness" or "modified". Pick your favorite and let's expose these functions there (under setuptools.fresh (or similar).

I can deal with the migration to the new name.

Thank you for the consideration

Before we expose these new public names, I do think we should seriously consider re-naming this module. dep_util doesn't convey very well the purpose. In fact "util" in any module name is usually superfluous. And "dep" doesn't tell me much.

I completely agree.

I'm thinking "fresh" or "freshness" or "modified". Pick your favorite and let's expose these functions there (under setuptools.fresh (or similar).

I don't have a strong opinion on this.

Some thoughts: Functions in the module currently only compare modification date, and the name "modified" is quite telling of what the module does, but maybe that's to close to implementation?
"fresh/ness" sounds off but maybe that's just me.
Something like "file_compare" may allow more types on comparisons in the future, but maybe that's too vague and not wanted (like creation date, file size).
setuptools.freshness.newer_group
setuptools.modified.newer_group
setuptools.file_compare.newer_group

I can deal with the migration to the new name.

Thanks! Feel free to close this PR as superseded by the new one.

Well that's weird. It used to be the case that if I pointed a PR to target a branch and then merged that branch into main, Github would repoint the original PR to main, but in this case, it closed this PR and I'm unable to reopen (the re-open is greyed out).

Aha! By re-pushing the feature/distutils-sync branch, I was able to re-open this PR.