flake init

[siph]

Description

I know the nushell maintainers aren't super familiar with nix and while I am
completely unqualified to explain nix to anyone, I can at least provide a tl;dr
about flakes and what the files do.

flake.nix

flake.nix is a (purish) function that describes how to build and package
applications. The inputs to this function are typically buildtime/runtime
dependencies (rustc, cargo, nushell, etc.), and developer tooling
(clippy, rust-analyzer, etc.).

The function outputs can contain multiple things including runnable
applications, developer environments, nix modules, etc.

flake.lock

flake.lock version-pins the inputs to the function. This means you get extremely
consistent reproducibility to the build function outputs. This is one of the
main reasons people love flakes so much.

result/

nix build will symlink the built derivation to the result directory.
This should be included as an entry into .gitignore.

I also left a some comments in flake.nix to help explain a few things.

[siph]

I've packaged this so that one could use nupm-lib to import nupm as a module and/or use nupm-test as a runnable application to test a local repository:

[kubouch]

We recently started a repository to store various integrations: https://github.com/nushell/integrations. If possible, flake.nix would be better stored there to avoid spreading too many files around unrelated to the project.

That being said, I think it's still too early to distribute nupm. We even released any version of it yet.

[siph]

Thanks for your feedback!

We recently started a repository to store various integrations: https://github.com/nushell/integrations. If possible, flake.nix would be better stored there to avoid spreading too many files around unrelated to the project.

I don't think so. That would need a much larger flake.nix that would encompass more than nupm.

I also don't agree that the files are 'unrelated to the project', they are very specific to nupm in that they package nupm and provide a developer shell for nupm (it's worth noting that the devshell doesn't have nushell-nightly yet so it's a work-in-progress).

Just to be clear. I've made sure this is as non-invasive as possible. The use of this flake is 100% optional and should have no effect on anything outside of the nix-ecosystem.

I'm also happy to maintain these files and be pinged for any problems/questions/help.

That being said, I think it's still too early to distribute nupm. We even released any version of it yet.

This isn't actually distributing anything, it's just packackaging nupm so that users don't have to write the nix expressions themselves. This isn't the same as being in nixpkgs.

I would also like to point out that nufmt has a flake: nushell/nufmt#41

[kubouch]

I mean, yes, it's related to the project, but we could quickly get our repository cluttered with all the different package manager files that would ultimately be our responsibility to maintain. @MangoIV made an external flake for Nushell here: https://git.sr.ht/~mangoiv/nu-shell.nix, so I guess it's possible to have a flake outside the project. Couldn't the flake pull from https://github.com/nushell/nupm instead of requiring local files? The advantage of https://github.com/nushell/integrations is that we can add some CI checks to test the packaging, and it is meant to be community-maintained, to avoid having the core team to maintain package manager and distro files in our core repositories.

The flake.nix in nufmt came before we had https://github.com/nushell/integrations, it should probably be moved there as well.

[MangoIV]

we can have inputs.nupm.url = ... inputs.nupm.flake = false, then nupm will get pinned to the most recent commit on the rev and is available as a store path via inputs.nupm

[siph]

You can absolutely package this outside of the source repo (this is how nixpkgs works). However, some users can find this quite cumbersome, for example nix run github:nushell/nushell is much easier to remember than nix run sourcehut:~mangoiv/nu-shell.nix.

I mean, yes, it's related to the project, but we could quickly get our repository cluttered with all the different package manager files that would ultimately be our responsibility to maintain.

I'm not sure I understand this comment as it seems very speculative. I never implied all package formats should be included in this repo. I would also like to point out that I volunteered to maintain these files.

The flake.nix in nufmt came before we had https://github.com/nushell/integrations, it should probably be moved there as well.

To be fair, this pr existed before that repository as well.

Seeing as the nufmt flake being accepted is the only reason I even opened this, I will close this.

Thanks very much for your time @kubouch @MangoIV!

[kubouch]

You can absolutely package this outside of the source repo (this is how nixpkgs works). However, some users can find this quite cumbersome, for example nix run github:nushell/nushell is much easier to remember than nix run sourcehut:~mangoiv/nu-shell.nix.

To make it less cumbersome, we started the nushell/integrations repo, so at least related package manager files could be in one place under the nushell org. Feel free to put it there.

I'm not sure I understand this comment as it seems very speculative. I never implied all package formats should be included in this repo. I would also like to point out that I volunteered to maintain these files.

Once we accept something to our codebase, it is ultimately the core team's responsibility to maintain it (or remove it if we can't maintain it). People come and go, so if you were in a situation unable to maintain it in the future it would fall on us. But it's great to see people wanting to help out and maintain stuff, I'd be happy to put the flake nushell/integrations.

To be fair, this pr existed before that repository as well.

Yeah, somehow I didn't notice it earlier.

[siph]

I'd be happy to put the flake nushell/integrations.

Such a flake would be quite a bit more complex as it would eventually hold derivations for many nushell projects and I'm not comfortable maintaining something like that, although I would love to use/contribute to it should someone take the initiative.

I can solve all these problems within my own projects so it isn't a big deal to me, I was just trying to upstream a solution.

Thanks again!