Adding flake.nix

[TornaxO7]

This helps nix-users to load a dev shell which helps to get started with contributing.

[RaySlash]

Hey, Great to see this. You can squash the commits and force-push. Also, please don't merge main branch into this branch.

git reset --hard HEAD^
git rebase -i HEAD~6       # double-check this please

Thanks.

[RaySlash]

In addition to the comments I have put in, would you be able to document this for the authors of this repository to see the changes clearly. Great work. Thank you.

[TornaxO7]

Also, please don't merge main branch into this branch.

May I ask why I shouldn't merge the main branch into this branch?

[RaySlash]

@TornaxO7 When you merge main into this branch, it might cause conflicts and unwanted behaviors. This answer on stack overflow describes it better. You can see General Code Conventions for nixpkgs for more information.

[TornaxO7]

@TornaxO7 When you merge main into this branch, it might cause conflicts and unwanted behaviors.

well that's the reason why I'm merging main into this branch: To avoid those conflicts or resolve them as early as possible?

This answer on stack overflow describes it better.

If I'm reading it correctly, this person explains why the "official" ways are doing this but this person doesn't say that it's not recommended to do it.

Maybe I'm missing the point? 🤔

[RaySlash]

I believe you can understand it easier if you visualize the branches separating of from one another. The main branch is the first branch which we make variations of. Upon creating a PR, the two branches main and add-flake in this scenario, is compared with one another and the differences in files are the contents of PR. If you can visualize yourself that the main branch is seperated from itself by adding a new add-flake branch.

To be more clear, The commit in which you merge main into add-flake, the commit difference would also include difference between two branches which is merged before the PR is mergedwhere you merge the changes. In this case, the main branch did not have any commits specifically when you merged main into add-flake. I would suggest you look into rebasing to resolve conflicts than relying on merge. It will help yourself to avoid shoot your own feet. 😆 🤞🏻

[TornaxO7]

@RaySlash I'll squash everything in the end, but not yet

[RaySlash]

Are you merging main using another branch into this branch due to any conflicts? You really don't have to stay update with main otherwise.

[RaySlash]

Few more changes to revert. I am aware you are still working on it. Great job. Thanks

[TornaxO7]

I believe you can understand it easier if you visualize the branches separating of from one another. The main branch is the first branch which we make variations of. Upon creating a PR, the two branches main and add-flake in this scenario, is compared with one another and the differences in files are the contents of PR. If you can visualize yourself that the main branch is seperated from itself by adding a new add-flake branch.

To be more clear, The commit in which you merge main into add-flake, the commit difference would also include difference between two branches which is merged before the PR is mergedwhere you merge the changes. In this case, the main branch did not have any commits specifically when you merged main into add-flake. I would suggest you look into rebasing to resolve conflicts than relying on merge. It will help yourself to avoid shoot your own feet. 😆 🤞🏻

Tbh. I still don't really understand why I shouldn't keep my branch up to date ;-;
Assuming there are two different branches, which were created from main a long time ago and both keep their state up to date with main: Yes, it can occur that only one of them has to fix some merge conflicts, but sounds correct to me.
Assuming both wouldn't keep their branch up to date and main didn't introduce merge conflicts for both branches. There's still a chance, that one of those two branches will get merge conflicts if one of them gets merged first or am I wrong here?

[RaySlash]

@TornaxO7 Changes looks good for now. Ill test everything once I'm home. direnv seems handy, thanks for the explanation. Also, in this scenario you want to use rebase than relying on merge. I strongly recommend you go through Git Documentation for rebase.

In this case of you working on a rev that split off from master to add-flake a while ago, and currently master have additional commits that are ahead of add-flake. You want to make sure you are updated with current master, you can rebase the branch to pick your changes to the top and import the additional changes from master below the changes you made. This would effectively keep your branch up to date with master with no conflicts. Instead, if you choose to merge master into add-flake, the new commits from master will stay on top of the changes you made. This could cause unexpected behaviours when merging. You can either choose to follow the old branch. I believe its safe to assume that your changes does not update any core files, instead its adding two files: flake.nix and flake.lock.

[RaySlash]

Additionally, would you be able to document this under docs/docs/install for users and contributors? Mainly, it need to contain info on how to use the flake as a package for users and devShell for contributors. Brief and concise would be best. Thank you

[RaySlash]

I tested your flake.nix and the nix develop functionality works well after adding a few pkgs such as:

ncurses
cmake
pkg-config
autoPatchelfHook

I did a rebase using your PR contents and add a few lines to make the nix build functionality work well. I have currently setup in my fork: RaySlash@01d7aa1 . I can confirm that both nix develop and nix build works from my end. Ill show a snippet from what I have done (see the complete file for full changes):

# For rustPlatform
nativeBuildInputs = with pkgs; [
  ncurses
  cmake
  pkg-config
  autoPatchelfHook
];

# `nix build` works
packages = eachSystem (system: {
  default = pkgsFor.${system}.callPackage mkRio { };
});

You can refactor your current flake.nix based on mine. Also, if you don't mind letting me do the PR, ill have my branch up as PR if that's alright by you as you are the first one to stumble across. Thanks.

[RaySlash]

I am also able to add the rio flake to my dotfiles and use following changes to accomodate it:

# flake.nix
inputs.rio.url = "github:rayslash/rio/flakeify";
outputs = inputs@{ nixpkgs, ... }: {
#...
}
# home.nix
{config, lib, pkgs, inputs, outputs, ... }: {
programs.rio = {
  enable = true;
  package = inputs.rio.packages.${pkgs.system}.default;
};
#...
}

[TornaxO7]

I tested your flake.nix and the nix develop functionality works well after adding a few pkgs such as:

ncurses
cmake
pkg-config
autoPatchelfHook

Huh, may I ask why you needed them? I just needed to do nix develop and cargo check and cargo run were running fine.

By the way, the unofficial NixOS discord server recommended me flake-parts. What do you think about it? Should we use that instead of nix-systems?

[RaySlash]

Huh, may I ask why you needed them? I just needed to do nix develop and cargo check and cargo run were running fine.

I was not able to compile as those packages were missing. It could be that you have those packages declared in your dotfiles.

By the way, the unofficial NixOS discord server recommended me flake-parts. What do you think about it? Should we use that instead of nix-systems?

That seems good. flake-parts would give us more flexibility with declaring System specific changes. i guess so. I got to check it out to see if its worth it. But currently, systems works well. We could do the change in a different PR. this would be initial flake init. What do you say?

[TornaxO7]

I was not able to compile as those packages were missing. It could be that you have those packages declared in your dotfiles.

Ah yes, I see what you mean.

That seems good. flake-parts would give us more flexibility with declaring System specific changes. i guess so. I got to check it out to see if its worth it. But currently, systems works well. We could do the change in a different PR. this would be initial flake init. What do you say?

Yeah, we can do that.

[TornaxO7]

@RaySlash alright, so I basically took your flake.nix and squashed everything.

[TornaxO7]

@RaySlash alright, I also added some ci to test the flake.nix since raphamorim wanted this. You can review it now.

[TornaxO7]

https://github.com/raphamorim/rio/actions/runs/7278497844/job/19832838648?pr=363#step:9:14

[RaySlash]

See this:

rio/README.md

Line 5 in fb689b7

🚧 Currently Rio terminal is in the process of transition to 0.1.x (new window system, loop, image protocol and etecetera). For any update you want to make to the terminal, please contribute to the branch `0.0.x` instead.

[RaySlash]

@TornaxO7 This looks good. everything looks meaningful. If I was to nitpick, I could find that few changes that has been reverted still does update the file even though contents are same. Also, about the documentation part. We can add the info for NixOS users to install using nixpkgs and flake and fact that they can use nix develop and nix build. Should we do this in a different PR or in the same one?

Also, if you did import my flake completely, can u add me as co-author of the commit? see more info about it here

<RaySlash@[email protected]>

[TornaxO7]

We can add the info for NixOS users to install using nixpkgs and flake and fact that they can use nix develop and nix build. Should we do this in a different PR or in the same one?

where would you add this info? In general I think that most people are aware of flake and/or can search the package on their own: https://search.nixos.org/packages?channel=unstable&from=0&size=50&sort=relevance&type=packages&query=rio.

Also, if you did import my flake completely, can u add me as co-author of the commit? see more info about it here

<RaySlash@45141270[email protected]>

Aye, will do

[TornaxO7]

@RaySlash done! :)

[RaySlash]

Looks Good. 🥳 Approved

[TornaxO7]

@raphamorim now it's up to you

[SergioRibera]

@TornaxO7 I have noticed a path that seems to be wrong, am I correct?

[raphamorim]

thanks for the work 🎖️