Possible to make Nix a non-requirement?

[spavikevik]

This project looks great, so happy to see this and happy that digitally induced is standing behind it. A huge thanks for creating it!

I would like to try it out for myself over weekends, but there is a stumbling block I have at the moment.

As a Mac user, for many reasons I am hesitant to install Nix on my Mac; Windows users may feel they have it even worse. I know the project itself is built using Nix, and I have no objections to it being that way, of course.

However, I would like to explore whether there are any possible paths to take to make it even more accessible to a wider community of people who use Haskell, but not Nix, as well as people who just want to get into Haskell but for whom Nix might be an overkill. It could be a stumbling block for potentially many people.

I am not sure whether you have any plans of offering it on Hackage, and I won't object much if you say the answer to that is no, but I believe there might be some alternative ways to not to have Nix be a hard requirement and I think many other people will agree with me and be able to offer even better suggestions than me.

Personally, for me, even if it is a simple shell script that downloads the project and installs any necessary dependencies would probably be a big boost.

P.S. I am willing to contribute anything in terms of developer time and assistance in my free time if you guys think this is possible.

[spavikevik]

P.P.S. the nix part seems to have generated quite a debate over on reddit as well.

[mpscholten]

Hey, first thank you for opening this discussion 👍

It could be a stumbling block for potentially many people.

Yes, I totally see this. E.g. installing nix on macos right now is sometimes even not working at all (see #93).

We have been thinking about using GitPod or the upcoming GitHub CodeSpaces to make it a lot easier to use IHP for the first time.

Windows users may feel they have it even worse

A bit off topic but in Windows it's actually working surprisingly well with the Linux Subsystem for Windows: https://www.youtube.com/watch?v=fM0WTMLdmVw :)

I am not sure whether you have any plans of offering it on Hackage, and I won't object much if you say the answer to that is no, but I believe there might be some alternative ways to not to have Nix be a hard requirement and I think many other people will agree with me and be able to offer even better suggestions than me.

We're open for this. This way you could try to use cabal instead of nix, right? We might also need to change some scripts and tooling which is calling nix-shell.

---

In general I'd rather have us spend the development time on making nix better instead of support multiple package management systems. Also certain advantages of IHP only work by using nix (e.g. the pinned versions of all the tooling). So in general I'm not a big fan of supporting non-nix versions of IHP.

[spavikevik]

@mpscholten

Thank you for the detailed response and explanation about your plans for IHP.

While I would like to see how CodeSpaces will work like; I'd pretty happy if I could use cabal as you mentioned here:

We're open for this. This way you could try to use cabal instead of nix, right? We might also need to change some scripts and tooling which is calling nix-shell.

Please let me know in what ways I can assist you to make that possible.

[jantebeest]

On MacOS 11 it's impossible to install even with Nix. I think most developers using a Mac will agree that it's already possible to install haskell and everything it requires using Homebrew, so being able to use cabal would be great. Then we can rely on our current package managers and setups to try out IHP.

IHP looks like something awesome, so I would definitely try it if I could. Keep up the great work.

[cies]

I really agree with the premise that Nix is not "just a package manager", those would be cabal-install and stack. I found stack worked really well for making sure builds "just work".

While I agree Nix is cool and an interesting choice for IHP, I do wonder why it was chosen over the two systems just mentioned (given those systems have a much wider adoption in the community).

[mpscholten]

We also need a way to manage e.g. postgres and other dependencies (e.g. imagemagick).

This is not possible with any other package manager. On larger web projects there's also no good way around npm packages. Then you'd have to use stack + npm + something else for postgres. With nix we can just use nix to manage all our dependencies, even npm packages and other system software.

[mpscholten]

Yes, it think we're the first framework mainly using nix as the package manager.

I know nix is very painful to set up on macos. E.g. we cannot merge https://github.com/digitallyinduced/ihp/pull/377 right now because of nix issues on macos.

But there is one big longterm advantage when comparing this approach to rails. We've lots of old rails projects. Whenever we have to fix some of these old projects, it's always a pain to get it working again. Different postgres version, wrong ruby version, wrong bundler version, some dependency that has to be managed by manually installation, webpacker ...

We also have old IHP projects, like from 2018. Sometimes we get small feature requests for these projects. Whenever we open these projects, everything really just works as if time was frozen :-) It's super great. No other framework gives this experience. I would love to have this experience with all the software projects in the future. So we need to stay committed to Nix to make this future happen.

[spavikevik]

@mpscholten Sorry I had deleted my comment about Rails as I didn't want to come off as insensitive about IHP's commitments. With that said, I'm happy to hear more about your reasoning behind using Nix.

[spavikevik]

So I guess as long as there are those of us who don't or can't use nix.. would you be able to support a community effort to get it working without nix? I mean, would you mind such a project in the first place? I imagine it could start as a fork, but depending on whether it is maintained or not it could potentially run into a dead end..

Then again, I am interested about what people who don't/can't use nix think about trying to make a distribution of IHP without nix. I personally don't know how much effort that would take, since it doesn't seem like a completely straightforward thing?

[mpscholten]

Sorry I had deleted my comment about Rails as I didn't want to come off as insensitive about IHP's commitments. With that said, I'm happy to hear more about your reasoning behind using Nix.

Don't worry. Totally happy to discuss all possible options.

So I guess as long as there are those of us who don't or can't use nix.. would you be able to support a community effort to get it working without nix? I mean, would you mind such a project in the first place? I imagine it could start as a fork, but depending on whether it is maintained or not it could potentially run into a dead end..

I think we could explore this direction and then see whether it's running well. The "official" way to get IHP running would then still be the nix based way.

Then again, I am interested about what people who don't/can't use nix think about trying to make a distribution of IHP without nix. I personally don't know how much effort that would take, since it doesn't seem like a completely straightforward thing?

Yes, maybe we can also try to find out the reasons why some people don't want to install nix and then just fix these. Maybe we can find a way to install nix "locally" on the system (instead of having a global /nix). This might be easier than doing a fork. Removing nix is really a lot of work. Also a lot of documentation would need to be rewritten to deal with a non-nix way.