Provide Nix flake, package and shell#61
Conversation
daimond113
left a comment
daimond113
left a comment
There was a problem hiding this comment.
Overall, while providing Nix support would be nice, I don't believe pesde fits the criteria as it is inherently impure. You must especially consider this if you plan on PRing to nixpkgs.
| buildNoDefaultFeatures = true; | ||
| buildFeatures = [ | ||
| "bin" | ||
| "version-management" |
There was a problem hiding this comment.
I actually made version-management in mind to be disabled when using Nix, as it manages pesde's and engines' executables, which is impure. Additionally, you'd most likely want wally-compat and patches enabled for Nix users.
| openssl, | ||
| dbus, | ||
| }: | ||
| rustPlatform.buildRustPackage (_finalAttrs: { |
There was a problem hiding this comment.
If Nix is to be added, I think I'd prefer for it to use crate2nix.
There was a problem hiding this comment.
I think I would agree for the packaging within this repository, but when upstreaming it to nixpkgs this would be a bad idea.
| pname = "pesde"; | ||
| version = "0.7.1"; |
There was a problem hiding this comment.
Ideally these would be read from the Cargo manifest.
What inherent impurity is there within pesde? |
Engine management and binary packages. |
That's fine, so as long as the program does not self-mutate where it is installed from. It is not a necessary concern to have, if there is a wider concern that would regard say, the manager(s) of Lua packaging for Nix as a whole, and not the use of an individual package manager within a system in an impure fashion (not everything need be perfect and pure). |
pesde does, as version management replaces its own executable with a version fetched from the internet. For engines & binaries, it hardlinks the executable in the bin directory to the name used whenever it is referenced by a project (dependency or not). |
I will make sure that feature is not enabled within the rework of this PR to use crate2nix, although I figure crate2nix adds a lot more ...bloat to the overall Nix for a project, especially considering flake-parts and all. Also, it seems to make it harder to use the packaging and shell without flakes, in the sense of, currently there is a shell.nix and a package.nix, which allows for both to be consumed by non-flake users. |
You needn't use Unfortunately for Nix, disabling the feature does not remove binary package executables, as it would inherently break them. This issue will hopefully improve in pesde 0.8 when we switch to using croshet, as we will generate ephemeral binary directories that we will append to |
|
Do you think it is worth holding off on packaging for Nix until 0.8, then? |
|
Probably so. If you wish, you can leave this PR as a draft, and I'll ping you when the required changes get pushed to main. |
|
Why the PR? We already have pesde-nix which uses FHS to get around impurities introduced by the entire concept of a package manager which fetches arbitrary packages from the internet. The package is made by an individual who is currently already associated with the project, it might even be worth merging in the organization itself to make it official. |
|
I was not aware of that project. |
3 participants
Hi! This adds several things for NixOS and Nix users to this project.
I can make a separate repository (presumably I would name it something like pesde-flake) to maintain these additions separately, if you should wish instead of incorporating them into your 0.7 branch.
I may also contemplate upstreaming this directly to nixpkgs and becoming its maintainer separately aside from the project itself, to provide this package manager for all nixpkgs users.
Usage
nix build .#ornix build .#pesdedirenv allowto be dropped into a shell automaticallynix develop,nix develop .#Maintenance
When you change the contents of your Cargo.toml or the Cargo.lock lockfile changes,
nix/package.nixwill require updating thusly; there is acargoHash, e.g.Replace the hash with "" and
nix build .#to get the new hash that should be provided where the old one was.The version within
nix/package.nixmust also be incremented alongside the repository changes.