My main concern with this (as with the Docker setup) is that each of these that we add in adds additional files to the base directory (which can be overwhelming to new devs) and gives us the illusion that we are officially supporting these installation methods. So if we change the Ruby version, gems, etc. we would have to update these files - but you're the only one who knows how to do that. And if we don't do that, we have an installation method that becomes outdated and loses its value.

I wonder if it would make more sense to have this available in the Wiki or docs rather than living in the codebase itself.

(nods) Getting good advice on how to set things up if you aren't running our core supported environment is definitely something we want, and/but D's right -- if we can't sustain it, it'll be counter-productive in the long run.

If we could get a write-up into the wiki about this, though, with a pointer from the read me, and a caveat as to the date it was written -- that would be a goodness!

This is gonna be kind of a long answer but I want to address all the point since they are definitely valid.

General Thoughts

Overall, I can't disagree with the point that any feature you add becomes a support burden. Which is especially concerning when it's a feature you don't have the bandwidth to learn about.

That said. I think the impact of any feature like this depends on size of surface area of it's interface.

This is a super advanced form of setup that few people will use, so even if it goes out of date the impact will be low. Furthermore, pretty much anyone setting up the repo with Nix probably has the skills to troubleshoot issues.

I feel like as long as this is kept away from the casual user it really isn't an issue. Call it unofficial install methods or something. Maybe don't even link to it off the main readme.

Why not just give it a shot? Worst case scenario if it gets stale you can just pull it later (I don't think this will be an issue at least until node18 support ends in 2025). All this really needs to be is a few lines added to Gemfile.lock and the flake.nix. At that point any developer interested in setting it up Nix will have no issues doing it.

Specific Responses

Base Dir pollution

My main concern with this (as with the Docker setup) is that each of these that we add in adds additional files to the base directory (which can be overwhelming to new devs)

The only file that really needs to be added to the base directory is flake.nix. The rest can go elsewhere and stuff like gemset.nix and flake.nix can be added to .gitignore.

Also not trying to challenge the statement but out of curiosity is it really that common for new people to be confused by the stuff in the main dir? I feel like there is so much config stuff in there already that 1 file more or less won't affect much.

Illusion of Support

gives us the illusion that we are officially supporting these installation methods

What if we either don't include a documentation page for it or mark it as an unofficial install method?

Docker Concerns

(as with Docker)

I actually think there is a massive difference between this and Docker. Nix requires much less compared to the Docker setup because it doesn't have to deal with nearly as many networking shenanigans. If you compare this PR to the docker one, this one doesn't change any of the specs, configs or database.yml.

Pretty much all the changes are sequestered to flake.nix, so a developer doesn't need to be concerned about modifying some systems test that has a download component and breaking compatibility with docker.

Versioning

So if we change the Ruby version, gems, etc. we would have to update these files

This Nix setup uses Gemfile.lock as its source of truth so it would auto-update.

Why not throw this in the wiki somewhere?

I wonder if it would make more sense to have this available in the Wiki or docs rather than living in the codebase itself.

Technically, this could be done. It does create a large amount of friction because nix wants all files to be in the Git index before it will use them. You end up with this really annoying flow of staging the nix stuff then un-staging it for every commit.

Just cherry-picking a couple of comments:

Worst case scenario if it gets stale you can just pull it later

The point is we aren't going to know if it's stale or not, and we likely wouldn't think of pulling it.

I feel like there is so much config stuff in there already that 1 file more or less won't affect much.

And if you say that line 15 times, you end up with 15 more files 😁 The point is that if we have Docker-related files, Nix-related files and setup files that use neither, you get more options but also more confusion. Anything that lives in the repo (regardless of how "official" it is) is findable and hence adds to the cognitive load of figuring out how to run the app. And if we don't document it, people will look at it and have no idea why it's there or when/if it's safe to get rid of.

Just doing some googling... is there no way to get out of the requirement to have the files in the index? Not 100% sure what this is, but would it help? https://github.com/hercules-ci/gitignore.nix

Just doing some googling... is there no way to get out of the requirement to have the files in the index? Not 100% sure what this is, but would it help? https://github.com/hercules-ci/gitignore.nix

Nah. Unfortunately this does the opposite, makes the flake look at less files not more.

I feel like there is so much config stuff in there already that 1 file more or less won't affect much.

And if you say that line 15 times, you end up with 15 more files 😁 The point is that if we have Docker-related files, Nix-related files and setup files that use neither, you get more options but also more confusion. Anything that lives in the repo (regardless of how "official" it is) is findable and hence adds to the cognitive load of figuring out how to run the app.

It's kinda hard to get phrasing right over text so I was probably unclear. My original comment was more of an aside where I was wondering how often that situation occurs. Like how often does someone say something like: "Hey why is there a Procfile and a Profile.dev"?

And if we don't document it, people will look at it and have no idea why it's there or when/if it's safe to get rid of.

That's a very valid point.

I don't think we've got any statistics, obviously. But I think the important thing to keep in mind is that HE is a very newbie-centric repo - many if not most of our contributors are very junior. Hence why I would err on the side of keeping things clean and simplified rather than giving us more options that would largely benefit more senior developers.

Nix being so closely tied to the git repo seems like a very odd decision... wonder if there's some git magic we can do to make your own workflow not quite so painful.

Nix being so closely tied to the git repo seems like a very odd decision... wonder if there's some git magic we can do to make your own workflow not quite so painful.

That is a valid point. I believe that is mainly tied to Nix flakes vs derivations, flakes being newer, more performant but technically unstable. I should explore doing this as a derivation, maybe the workflow becomes easier.

2 followup questions:

1. How about merging the Gemfile.lock and SCSS changes to enable someone using a flake to use the repo?
2. What would an alternative setup method need to look like for you to want to add it to the project?

1. I'm good with that.
2. That's an excellent question. I think if we can move the relevant files into a subdirectory, I'd feel better about that. I'd still think carefully about the maintenance load and see if there are ways to reduce that. Probably my ideal would be to provide information on how to do the setup without checking those files into git so we're not "on the hook" for them.

I want to test the setup with nix, since it can be beneficial for me in the long run. Will try to do it in 2-3 months.

I think devs with windows os are more prone to set up nix, since it can abstract a bit of the mess when using Linux from wsl.

I want to test the setup with nix, since it can be beneficial for me in the long run. Will try to do it in 2-3 months.

I think devs with windows os are more prone to set up nix, since it can abstract a bit of the mess when using Linux from wsl.

I've never used it with WSL. Only as a Linux os/ package manager. If you go whole hog and use it as an OS there are sooo many foot guns.

I don't think Ruby is necessarily the best environment for it. I also in general think that this project is a bit of a poor choice for nix (this project takes a potential JavaScript dependencies and uses gems to provide them. The installation of those gems can be a pain in the ass sometimes).

I was mainly setting it up for personal use because I have a laptop that wouldn't be able to run it otherwise.

Not trying to discourage you. But just warning you that it makes you want to pull your hair out sometimes. On the other hand, sometimes you're missing a dependency and you literally put one line of code in your config file and everything's fixed.