tomberek: Some thoughts on 1565 itself:

• My understanding, from accidentally stepping into ~this (but, in a courtesy PR to another project he works on) anton is profoundly (and understandably) unhappy/frustrated with how this PR went.
• It's unfortunate people keep finding that and commenting on it. When it comes up, it triggers a frustrated outburst (or a whole flurry of them). IMO the discussion should be locked regardless of who closes it.
• Per the above (and having been in roughly this position myself), I would be extremely surprised if he will do any more work on it. Even if he did, I think it would be a bad idea to try. He'll be agitated. It'll probably be testy and delicate. I can't imagine this moving forward without someone else picking it up in one or more new PRs.

General scattered thoughts on the installer:

• The installer has moved on since 1565 was done. Even if it isn't enough to merit re-doing it from scratch, it's enough to require thinking through how the PR's intent should affect those changes.
• My ~feelings on it are vaguely in line with what Anton expresses. I find the ongoing installer pain as a little embarrassing. I find it frustrating that the project needlessly-squanders good-will on first encounters, and even more frustrating that I don't see much interest in fixing it. I find responding to people having trouble with stuff that's already fixed in master but unreleased frustrating. Everyone's squeamish about touching it. If someone wants to make a larger change, there's no obvious group of stakeholders to seek buy-in from.
• I'd like it to be a lot better. And I don't actually think it'd be that hard. But I'm also not looking to adopt it, so I'm trying to just put it out of mind until some others are stepping up.
• After basic support for testing it in CI merged in March, it should be much easier to work on the installer now than it used to be.
• I (personally) see the obvious next step as investing in an installer test suite that stakes out both what the installer does and should support (including whatever portability issues matter). I've been trying to fish for interest in this (ex: https://discourse.nixos.org/t/installer-test-suite-small-project-s-high-leverage-help-wanted/13662) without much luck so far.
• I think a predictable release cadence as Eelco describes in https://discourse.nixos.org/t/nix-release-schedule-and-roadmap/14204/2 will help with improving the installer. It'll provide a stronger feedback signal on whether old issues have actually been fixed, and a commitment to maintain a releasable master branch could make an installer test suite a good lever for focusing attention on fixing broken scenarios.

General scattered thoughts on the installer:

• The installer has moved on since 1565 was done. Even if it isn't enough to merit re-doing it from scratch, it's enough to require thinking through how the PR's intent should affect those changes.
• My ~feelings on it are vaguely in line with what Anton expresses. I find the ongoing installer pain a little embarrassing. I find it frustrating that the project needlessly-squanders good-will on first encounters, and even more frustrating that I don't see much interest in fixing it. I find responding to people having trouble with stuff that's already fixed in master but unreleased frustrating. Everyone's squeamish about touching it. If someone wants to make a larger change, there's no obvious group of stakeholders to seek buy-in from.
• I'd like it to be a lot better. And I don't actually think it'd be that hard. But I'm also not looking to adopt it, so I'm trying to just put it out of mind until some others are stepping up.
• After basic support for testing it in CI merged in March, it should be much easier to work on the installer now than it used to be.
• I (personally) see the obvious next step as investing in an installer test suite that stakes out both what the installer does and should support (including whatever portability issues matter). I've been trying to fish for interest in this (ex: https://discourse.nixos.org/t/installer-test-suite-small-project-s-high-leverage-help-wanted/13662) without much luck so far.
• I think a predictable release cadence as Eelco describes in https://discourse.nixos.org/t/nix-release-schedule-and-roadmap/14204/2 will help with improving the installer. It'll provide a stronger feedback signal on whether old issues have actually been fixed, and a commitment to maintain a releasable master branch could make an installer test suite a good lever for focusing attention on fixing broken scenarios.

In reply to @tomberek:matrix.org
I’ll take a look at existing tests and see what gaps there are. At the least try to assess old and new installers. With luck this can be added to an upcoming milestone.

In reply to @jaen:matrix.org
Hello, is this the right place for "nix is behaving very weirdly when trying to build a package flake output and I don't know why"?

In reply to @abathur:matrix.org
I'll at least aspire to find some time to read over the changeset and take some notes, as well

What's the consensus on languages to be used for scripts?

So far, I have a couple of bash scripts to easily build / run the fuzzers I have so far.
But as I am making diverse harnesses (one exercising only the parsing, other parsing and evaluation, and later maybe other components - daemon...), with different sanitizers, those scripts are growing, and I want them to take options.

Now, I feel like using python with https://docs.python.org/3/library/argparse.html is a really neat way of providing a nice interface for my script (and also more maintainable than bash).

In reply to @pamplemouss_:matrix.org

What's the consensus on languages to be used for scripts?

So far, I have a couple of bash scripts to easily build / run the fuzzers I have so far.
But as I am making diverse harnesses (one exercising only the parsing, other parsing and evaluation, and later maybe other components - daemon...), with different sanitizers, those scripts are growing, and I want them to take options.

Now, I feel like using python with https://docs.python.org/3/library/argparse.html is a really neat way of providing a nice interface for my script (and also more maintainable than bash).