I have a feeling this question has been asked 1000...
# general
I have a feeling this question has been asked 1000s of time but I'm having a hard time searching for the answers I need. When I run
pants tailor ::
to boostrap my repo, I end up with a plethora of
files in every subfolder of all the apps we have (our devs love folders for module separation). Is this really best practice? How do I convince my devs that all these files are necessary and the best practice? especially when they will never be customized or touched after they're created. Can I create one or two per service that would contain all my information necessary for building pex, environments, docker images, etc?
You can create your own, but then you are creating your own. You have to weigh devs being annoyed? by the presence of files they don't have to maintain vs having less files but having to maintain them. "Best practice" here is a bad phrase that just hides a real tradeoff. The best practice is picking your tradeoff.
Ideally Pants wouldn't need the boilerplate BUILDs, but it does. Its confusing to be sure.
Sometimes I managed to use recursive globs to avoid this, but I think this has caching implications? E.g. for my tests there is just one BUILD file that does somethinglike
in the sources list.
That shouldn't affect caching - those globs expand internally to file-level targets
So @polite-art-32636 you absolutely can have a handful of higher level BUILD files with recursive globs
Ideally that would be what tailor generates, since
now make it easy to override metadata for a specific file in that high-level BUILD file. BUT - the problem is when you do want to introduce a lower level BUILD file for some reason, there will now be two providers of metadata for the same file, which today confuses Pants. There is an idea of accumulating metadata across all targets that own a file (with the innermost setting for a particular field overriding outer ones) but that is not implemented yet. Once it is, having a small handful of BUILD files will be much more practical.
And yeah, ideally ideally we would not require dummy BUILD files at all. It is an unfortunate legacy.
ah interesting background. you think tailor will be later modified to reduce the amount of extraneous BUILD files? I do like the idea of having a ci tool to ensure proper config vs me managing it all by hand. I just know how much whining I'll hear about these extra files
Yeah, that whining seems justified to me. Especially when those files have basically no information, they are just placeholders for where you might one day want to introduce extra metadata.
I would love to get rid of them! At the least, we could add an option to tailor to be more minimal.
If you need to split up a recursive glob target later you can always remove it and run tailor again.
In Pants v2 we went pretty far in getting rid of BUILD boilerplate (through defaults, naming conventions and, most of all, dependency inference), but we didn't go far enough
I conveniently did not mention all of the BUILD files when demoing pants in the StackStorm project. I focused on all of the benefits including lockfiles and improved UX for developers over the tangled mess of a Makefile no one wanted to touch. Only after I got the green light did I explain that these minimal BUILD files would be generated and included throughout the repo - and I added a CI check to ensure people didn’t forget to run tailor.
I’m a happy recursive globber - 1 BUILD file per project, never had an issue with it. Value to me is reduction in visual clutter (which I think something like VSCode can hide) - but it’s mostly just seeing 50 BUILD file options when I try to shortcut open a BUILD file that irks me. Recently a huge annoyance after sveltekits latest update too - with all routes having the same filename 🤦‍♂️
"happy recursive globber" should be on your linkedin profile
☝️ 1
I think my LinkedIn profile states that I am an “avid lover of long walks on the beach, unnecessarily complex conversation, and Oxford commas”
That would be gold if you left off the embedded Oxford comma of course.
That’s more of a twitter profile
thanks yall I'm going to poke at this more