from pants.engine.target import COMMON_TARGET_FIELDS, SingleSourceField, Target


class ProjectVersionSourceField(SingleSourceField):
    alias = "source"
    help = "Path to the file with the project version."
    default = "VERSION"
    required = False


class ProjectVersionTarget(Target):
    alias = "version_file"
    core_fields = (*COMMON_TARGET_FIELDS, ProjectVersionSourceField)
    help = "A project version target representing the VERSION file."

I also have a

python_test

target in addition to the instance of that custom target:

version_file(
    name="main-project-version",
    source="VERSION",
)

python_tests(
    name="tests",
    dependencies=[
        ":main-project-version",
    ],
)

When I run

pants test tests/cli

, it runs fine, caching the results. I expect that after I modify the contents of the

VERSION

file used by that target, the test target should be considered changed and the

--changed-since

does suggest that this is the case since the dependencies have been declared correctly. However, caching mechanism is broken - no matter the changes made to the

VERSION

file, the test never actually runs, relying on the local cache. I think I may need to request some kind of rule for this target so that the digest of the files could be evaluated to invalidate the cache, but not sure what should it be? Replacing the custom target with the

file

built-in target makes caching works fine again upon subsequent changes to the

VERSION

file.

I suspect this may be something related to the

await Get(Digest, PathGlobs([f"{target.address.spec_path}**/*"]))

, but I am not sure what union rule should that be part of, if any? 😕

I have a repro to check out and modify the plugin code, if required https://github.com/AlexTereshenkov/cheeseshop-query/pull/41

if not, I suspect you need a codegen to translate the VERSION file from a

version_file

into a

file

file..

if not, I suspect you need a codegen to translate the VERSION file from a

version_file

into a

file

file.. (edited)

oh I see. Is that something trivial I'd be able to see how we do for the built-in codegen or is it something esoteric?

there're only a few things that goes into the test execution rule besides files and env vars that could invalidate your test run... (I'm not too familiar with the implementation of that, so I draw a blank what else there may be..) so I have no idea how to invalidate the cache with anything else than dumping a file in there.. 😄