How hard would it be to support absolute paths for resource targets’ sources? The issue originates from the following dilemma: our dev environment assumes access to a globally replicated network file system, where lots of resources and binaries are installed, but bringing those resources into an application at runtime is a practice we’d prefer to avoid (having it documented in a BUILD file is much more maintainable and easier to track dependencies from) and is not possible anyway when the dist target is Docker or some other environment that does not have such access. On the other hand, bringing those resources under the project requires us to manually keep them up to date ourselves, not to mention potentially resulting in lots of things you’d rather not have in source control. From our perspective, allowing Pants to bundle resources and data into binaries and distros from network paths is a good solution that balances these issues.

One issue that comes to mind is file watching. How would Pants know when those external files have changed so it can invalidate builds that include them?

In this case they are immutable (unless you refer to a release (sym)link) as everything is installed on that file system via a specific project release.

Ah, ok, so something could be made to work in practice perhaps

@happy-kitchen-89482 What’s your impression on how hard this would be? Is it on the same level as when I implemented a plug-in for “relocatable resource” (a la file) and doable by a newbie or are we getting into the land of rust/engine internals?

We do already support immutable sources fetched via HTTP: https://github.com/pantsbuild/pants/pull/15457

Maybe that already works?

Indeed file:// already works (we use this in pants.toml for any binaries it needs from the outside world like pex or scc). Interestingly, just prepending file:// to an invalid file path in the source field shows Pants does indeed try to find it (raising invalid field error reporting 0 files found instead of raising a no abs path error). Changing to a valid file path gets us further: it does try to package, but it gets stuck in an infinite loop of retries.

huh

Regular resource target.

Even more surprised

Idk, wouldn’t think too much of it since now I can’t repeat the behavior of it continuously trying, but restarting from “file system changed” — only the “0 files found when expecting 1” error now. The bit about using file:// in the pants.toml config is still a thing though!

envvar interpolation into the path of the file?

Yeah

That would be a feature to add I guess