3 ms·
It shouldn't screw up reproducibility, but rather exposes what kind of unexpected state can leak in. If your build system knows what time it is and that can af
by jrockway 5y ago
It shouldn't screw up reproducibility, but rather exposes what kind of unexpected state can leak in. If your build system knows what time it is and that can affect whether or not it compiles, that's a reproducibility problem.
- mlyle 5y ago> If your build system knows what time it is and that can affect whether or not it compiles, that's a reproducibility problem. The very first example is of this: // trigger a compile error if we're past a certain date todo_or_die::after_date!(3000, 1, 1); // its the year 3000! And the second and third examples (this is all of them) are explicitly relying on non-versioned, external state leaking in, too. // or a GitHub issue has closed todo_or_die::issue_closed!("rust-lang", "rust", 44265); // GATs are here! // or the latest version of a crate matches some expression todo_or_die::crates_io!("serde", ">1.0.9000"); // its over 9000!
- iudqnolq 5y agoBut the issue is that the time your build process observes changes, not that you add a place that observes the time. If you're not fakeing time already it'll end up in all sorts of other places.
- jrockway 5y agoYup, that's exactly what I was hinting at. This sort of statement makes it clear that there is an undesired connection to the system clock, but of course all those tests that use time.Now() or whatever are equally likely to become faulty.