You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This provides a new temporary directory that is always cleaned up for each build configuration, is much better for unit testing and mocking, and removes the ridiculous levels of indentation we have for 90% of the code in build and that is keeping us from applying good programming practices, like context managers (and auto formatting? ;) ). I also think it's much easier to read the try/except, and "build_on_each" is a clearly defined concept, and still reads nicely linearly. See #558. Should wait until at least #484 goes in.
The text was updated successfully, but these errors were encountered:
Well, yes, it is kinda tempting. In fact, I already did it once in #458, but rolled it back when I decided not to use context managers for the logging.
In that example, eh, it wasn't as clean as I had hoped. I think the complication for the linux one is that many configs share one container, so each build_one invocation carries a lot of baggage.
I'm probably too close to judge, and certainly not willing to say that the level of indentation in linux.py especially is good per se, but there might be a readability benefit to keeping it as one function (or 'build script') versus breaking it out? not sure.
But if we do decide to change it, we should try to do so when we don't have a lot of big PRs around - those merges could be scary!
henryiii
changed the title
Factor our run_on_each
Factor out run_on_each
Feb 5, 2021
I'd like to make the following change. The current structure of the build function looks like this:
I'd like to refactor it like this:
This provides a new temporary directory that is always cleaned up for each build configuration, is much better for unit testing and mocking, and removes the ridiculous levels of indentation we have for 90% of the code in build and that is keeping us from applying good programming practices, like context managers (and auto formatting? ;) ). I also think it's much easier to read the try/except, and "build_on_each" is a clearly defined concept, and still reads nicely linearly. See #558. Should wait until at least #484 goes in.
The text was updated successfully, but these errors were encountered: