🤔

You can have a custom target type build_properties() or whatever, which takes whatever args you need to generate the file.

And your task’s

prepare_resources()

method can be quite simple.

I see, let me go over the

ResourcesTask

again .. no I think I can connect the dots better

Thanks a lot @happy-kitchen-89482 !

No problem, let me know if you run into any more problems!

I have an example of a custom

ResourcesTask

but I’d need to sanitize it before posting it

I’ve been looking at

prepare_services.py

as a reference .. but that one seems to use a very specific

.services

property on the target

Right, but you can define your own custom target type if you need to

What goes in your build.properties?

Does, say,

jvm_app

already have all the data it needS?

right now just the git sha

Oh, so that would be a yes… 🙂

In that case, you don’t need a custom target type

Just implement

find_all_relevant_resources_targets

to only return

JvmApp

targets

And implement

prepare_resources

trivially

I’m not sure I’m making sense

All makes sense so far .. only the “custom target” would have been outside of what I’ve already tried

so then I get

chroot

as a the path, right? the question is do I have to add the generated file back to the

target

in the

prepare_resources

method somehow?

I guess that trivially is very subjective 😅

I wonder if I am still on the right path .. Currently I am trying to get my generated

build.properties

included in

self.context.products.get(‘resources’)

. There is an

.add

method on that thing .. but honestly I am pulling straws now ..

is starting to miss the types 😅

My current state of

prepare_resources

..

path =  os.path.join(chroot, 'build.properties')
            resources = self.context.products.get_data('resources', lambda: defaultdict(MultipleRootedProducts))
            classpaths = self.context.products.get_data('runtime_classpath')

            with safe_open(path, 'w') as output:
                <http://self.context.log.info|self.context.log.info>('file={}'.format(path))
                output.writelines( …  )

            # only for resources?
            resources[target].add_abs_paths(chroot, [path])
            classpaths.add_for_target(target, [('default', chroot)])

The file gets generated but I don’t see it anywhere in the

/dist

dir after running

./pants bundle

is there a way to get the

clean-all

goal to wipe out the cache? i've been running into an issue where data under .cache is apparently preventing a complete pex build

don’t believe so - the buildcache is generally intended to persist well beyond the lifespan of .pants.d etc. the

clean-*

goals could use a rethink tho - ideally there’d be layers of cleaning.

but if it is pex cache related, it's not in the buildcache anyway, right

pex also has its own cache controlled via

PEX_ROOT

env var - in our monorepo, we pass

PEX_ROOT=${REPO_ROOT}/.pex

so that it’s at least a little more local.

unclear, but likely

you could always point

PEX_ROOT

to .pants.d/.pex or something which would cause it to get wiped via a

clean-all

i'm talking about

.cache/pants_backend_python_tasks_python_binary_create_PythonBinaryCreate

, that's in the buildcache right?