> For ourbuild system we had to check s3 This isn't a build system. What you're doing isn't building. Trying to use a build system to do what you're doing is a

> For ourbuild system we had to check s3 This isn't a build system. What you're doing isn't building. Trying to use a build system to do what you're doing is a bad idea. Using make to do what you're doing is a bad idea too, but it works because its just a shell script alias thing and not a build system. If its not something you can statically generate based on your code, and only your checked in code, at a certain revision, its not something you're building. >If I have some bazel select criteria C that resolves to a build action A, and then later in time I need for the exact same criteria C to instead build A2 (an upgraded version of A that is not backward compatible), this is a problem. You update the select rule. The select rule is version controlled. There's no timestamping anywhere, only what is at HEAD at revision X vs. revision Y. If you check out the older revision, you'll use the old criteria. The new one will use the new criteria, no matter the time. >I am NOT saying someone should ever use a timestamp as an actual part of versioning. Yet you're advocating make, which does exactly that ;) >but what if I need A from the old revision but I need Foo and Bar from the newest revision? You don't. You should never need to mix different revisions because everything is always buildable at head. If you mean you have some data file that's incompatible with your current schema or something then that's a different question, but again has 0 to do with your build system. To make it crystalline: versioning your data is not the same thing as versioning your builds. Bazel solves the first problem, because bazel is a build system. You seem to be trying to use bazel for something its bad at and then complaining that its a terrible tool because you're trying to version cron-generated, non-hermetic data files as part of your build process, which like yes bazel is bad at because that's not a build artifact, its an external non-hermetic data artifact. Pass your non-hermetic model data into your hermetic production binary via a flag. Separate your concerns. Problem solved. >The fact that you cannot admit that bazel might not solve every problem and that if bazel presents an annoyance it must be down to someone misusing it is seriously alarming. Except that I was right. Bazel is indeed not good for what you're doing, but that's because you're not managing builds, but ML model data. You're attempting to use a build system for managing not-builds. You're experiencing pain. This is not a surprise. Its a classic example of the XY problem. You: "Bazel is a terrible build system, it causes pain and shouldn't be used" Us: Some discussion Conclusion: "What you're doing isn't managing build artifacts, so of course a tool designed to do that isn't solving your problems. Dogmatism helps here. Use a build system to manage your builds and a different tool to manage your ML models.