@remko I mentioned you in the maintainers. Let me know if you don't want to be mentioned there. Thanks again for providing this nice piece of software and hopefully this small PR will allow using it for even wider audience 👌

@Kranzes I saw that you commented on the earlier PR on age-plugin-se and I'm wondering if you would want to look at this one as well.

I'm now building the plugin directly from source instead of downloading the binary like you suggested here.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/how-to-get-a-new-package-merged-into-nixpkgs/60900/1

I am not sure wether remko belongs into the maintainers field

@remko I mentioned you in the maintainers. Let me know if you don't want to be mentioned there. Thanks again for providing this nice piece of software and hopefully this small PR will allow using it for even wider audience 👌

I don't think you should add the creator of original software as a maintainer in nixpkgs unless they actually want to maintain this nixpkgs package. Correct me if I'm wrong but from a quick look at their profile I don't think remko is using Nix.

Hey, I pinged him above and he reacted with the heart emoji ❤️ 5 minutes later with his other account https://github.com/remko-bw so I assumed it was okay for him.

I'm happy to remove him and do to the maintenance myself if this is a blocker 👍.

Again this is my first contribution so I apologize if I'm not able to follow all conventions and please teach me 🙇

EDIT: added 3 missing words (sorry for my dyslexia)

Correct me if I'm wrong but from a quick look at their profile I don't think remko is using Nix.

Yes I'm highly confident that he is not using Nix 👍

I don't know of any guideline that requires that they use nix; the idea of the "maintainer" field is that they are pinged whenever there are PRs on the package and can help with the packaging.

If the upstream is willing to do that, I see no issue having them as a maintainer here 🤷

Thanks @eclairevoyant for taking the time from your day. You gave very pleasant feedback which helped me to learn and I really wish I can be helpful in this community in return. If I ever see you IRL I'm happy to offer a beer or soda to you 🍻🥤🤝.

btw I don't have merge access, so a committer would have to review and merge

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/prs-already-reviewed/2617/2282

I get a build error: https://paste.fliegendewurst.eu/jEnz8b

error: Invalid manifest (compiled with: ["/nix/store/3zy8cys6ar5m5400928wh69sw2ayg55a-swift-wrapper-5.8/bin/swiftc", "-vfsoverlay", "/build/TemporaryDirectory.tM3i46/vfs.yaml", "-L", "/nix/store/66bzf0bkzbsk8iwk55i89nsxbd112p0w-swiftpm-5.8/lib/swift/pm/ManifestAPI", "-lPackageDescription", "-Xlinker", "-rpath", "-Xlinker", "/nix/store/66bzf0bkzbsk8iwk55i89nsxbd112p0w-swiftpm-5.8/lib/swift/pm/ManifestAPI", "-swift-version", "5", "-I", "/nix/store/66bzf0bkzbsk8iwk55i89nsxbd112p0w-swiftpm-5.8/lib/swift/pm/ManifestAPI", "-package-description-version", "5.8.0", "/build/source/swift-crypto/Package.swift", "-o", "/build/TemporaryDirectory.hZJny3/swift-crypto-manifest"])
Warning: supplying the --target argument to a nix-wrapped compiler may not work correctly - cc-wrapper is currently not designed with multi-target compilers in mind. You may want to use an un-wrapped compiler instead./build/TemporaryDirectory.hZJny3/swift-crypto-manifest: error while loading shared libraries: libdispatch.so: cannot open shared object file: No such file or directory

@SuperSandro2000 & @FliegendeWurst I fixed all comments you had. Anything else I should still do or would you like to approve this?

Formatting CI fails as:

Please format them using the Nixpkgs-specific nixfmt by going to the Nixpkgs root directory, running nix-shell, then:

nixfmt 'pkgs/by-name/ag/age-plugin-se/package.nix'

The package itself looks good to me, however I can't test it.

@onnimonni Please ensure to use nixfmt-rfc-style here, from nixos-unstable or newer.

Would it be possible to add Linux support (e.g. by repackaging with swiftpm2nix)? Currently not having Linux support means it's not possible to rekey secrets for age1se identities on Linux (even though the plugin isn't used for authentication, it's still needed for rekeying).

Also the upstream Package.swift specifies swift-crypto should be up to version 3.0.0, meaning last version before 3.0.0, meaning 2.6.0, but in the derivation it's 3.7.1. It still compiles fine since the package only allows macOS, and on macOS the dependency isn't used, but you might want to change it if adding Linux support. (Maybe this is what was causing the manifest issue when compiling on Linux?)

nevermind, upon further testing the manifest issue seems to be unrelated, and also swift-crypto 1.x, 2.x, and 3.x are all mostly API-compatible so that shouldn't be an issue. Good news though is that packaging with swiftpm2nix seems to solve the manifest issue and enable compilation on Linux :)

Also-also, if it will remain macOS only, then maybe it would be possible to patch out the swift-crypto dependency altogether, since it isn't used?

Can you rebase this on top of the latest nixos-unstable and add the plugin to the list inside pkgs/by-name/ag/age/package.nix?

Would it be possible to add Linux support (e.g. by repackaging with swiftpm2nix)? Currently not having Linux support means it's not possible to rekey secrets for age1se identities on Linux (even though the plugin isn't used for authentication, it's still needed for rekeying).

Also the upstream Package.swift specifies swift-crypto should be up to version 3.0.0, meaning last version before 3.0.0, meaning 2.6.0, but in the derivation it's 3.7.1. It still compiles fine since the package only allows macOS, and on macOS the dependency isn't used, but you might want to change it if adding Linux support. (Maybe this is what was causing the manifest issue when compiling on Linux?)

nevermind, upon further testing the manifest issue seems to be unrelated, and also swift-crypto 1.x, 2.x, and 3.x are all mostly API-compatible so that shouldn't be an issue. Good news though is that packaging with swiftpm2nix seems to solve the manifest issue and enable compilation on Linux :)

Also-also, if it will remain macOS only, then maybe it would be possible to patch out the swift-crypto dependency altogether, since it isn't used?

This goes well beyond the scope of my current nix/age/swift understanding. I'm happy to let someone more experienced to continue from here to fulfil all of these wishes.

It seems that getting this merged is not that easy and I will just need to rely on installing it from homebrew instead. This is a bit sad since I would really want to use nix more not less.

Can you rebase this on top of the latest nixos-unstable and add the plugin to the list inside pkgs/by-name/ag/age/package.nix?

Done and done. I hope I ran the nix formatter properly too and it doesn't now give errors.

$ nixfmt pkgs/by-name/ag/age-plugin-se/package.nix pkgs/by-name/ag/age/package.nix maintainers/maintainer-list.nix

@andre4ik3 IMO if this package works on darwin, this can be merged as-is with further discussion on refactoring for linux later.

It seems that getting this merged is not that easy and I will just need to rely on installing it from homebrew instead. This is a bit sad since I would really want to use nix more not less.

Until it's merged you can use an overlay, e.g. something like this

(final: prev: {
  age-plugin-se = final.callPackage ./path/to/age-plugin-se/package.nix { };
})

Then simply use age-plugin-se like a normal package name everywhere else in Nix (where the overlay is applied, of course)

If using an overlay, final.callPackage would be better (final should generally be preferred)

Merging this as It works on darwin and is marked as such. Linux support, which I do have a personal interest in, can be done in a new PR. :)

Thanks for your patience & work @onnimonni! 🎉