fix(nix/eval.cc): move call to fs::create_directory out of assert

[xokdvium]

If the call is inside the assertion, then in non-assert builds the call would be stripped out. This is highly unexpected.

Motivation

I was looking through recently merged commits and ran across b5c8865 and this really stood out to me. I left a comment in the original PR #11650 (comment), but that did not get any traction. So I'm submitting this PR so this does not get lost.

Context

#11650

Priorities and Process

Add 👍 to pull requests you find important.

The Nix maintainer team uses a GitHub project board to schedule and track reviews.

[xokdvium]

CC @Ericson2314. I'm not familiar with the code at all. But just looking at the diff b5c8865 this does not look correct to me.
I'm also somewhat confused by this usage of assert. Is this directory not existing an invariant maintained by nix at all times and would never occur?

[Mic92]

good catch

[Mic92]

@mergify queue

[mergify]

queue

🛑 The pull request has been removed from the queue default

The merge conditions cannot be satisfied due to failing checks.

You can take a look at Queue: Embarked in merge queue check runs for more details.

In case of a failure due to a flaky test, you should first retrigger the CI.
Then, re-embark the pull request into the merge queue by posting the comment
@mergifyio refresh on the pull request.

[Mic92]

@mergify rebase

[mergify]

rebase

☑️ Nothing to do

• any of:
  • #commits > 1 [📌 rebase requirement]
  • #commits-behind > 0 [📌 rebase requirement]
  • -linear-history [📌 rebase requirement]
• -closed [📌 rebase requirement]
• -conflict [📌 rebase requirement]
• queue-position = -1 [📌 rebase requirement]

[Ericson2314]

Thanks! I think we always do asserts, but this is still better. (Indeed, always doing asserts is a work-around for mistakes like this.)