Less repetitiveness in Nix files

[doronbehar]

I think you mentioned this small concern regarding this repetitiveness, here it is fixed now.

[wiktor-k]

Yep, this looks great 👍! Thank you very much 🙇‍♂️

I'll merge it right away.

I wonder if the package.nix file could be used to update the pysequoia package in nixpkgs... it does refer to other files (is not standalone). If so I'd be happy to know how to do it 😁

Have a nice day! 👋

[doronbehar]

I wonder if the package.nix file could be used to update the pysequoia package in nixpkgs... it does refer to other files (is not standalone). If so I'd be happy to know how to do it 😁

That's a topic frequently discussed in the Nix ecosystem :) Basically the generalization of your question is: If a certain project includes a flake.nix and all that Jazz, why should Nixpkgs add that project as a package and "ignoring" the project's natural support for Nix users? My answer would be as follows:

First of all, it is possible to configure your NixOS system while referring directly to pysequoia's flake.nix, and not to rely upon Nixpkgs' pysequoia's expression and possibly Nixpkgs' slow updates. However, this requires configuring your system with flakes support, and currently it is a bit tedious to do so, in terms of Nix coding. And in contrast, including pysequoia in Nixpkgs as it is included now, allows for easier integration with the rest of Nixpkgs, and for PRs touching pysequoia's dependent packages to change / patch pysequoia in conjunction with other packages in Nixpkgs.

Also, you should remember that although flakes are so cool, they are still in an experimentation phase sort of (see this discourse thread and this RFC). Hence people don't want to make Nixpkgs a repository that relies on a flake enabled Nix to be fully functional.

In the ideal future, perhaps projects like this will be included in Nixpkgs via a flake reference, and not via an almost copy pasted package.nix file from here to Nixpkgs. Until then, the best thing we can do is to make this copy-paste an easy task as possible.

[wiktor-k]

In the ideal future, perhaps projects like this will be included in Nixpkgs via a flake reference, and not via an almost copy pasted package.nix file from here to Nixpkgs. Until then, the best thing we can do is to make this copy-paste an easy task as possible.

Hmm... so package.nix cannot go directly to the nixpkg repo since it also refers to Cargo.toml and other files in this repository?

Is there a semi automated way to generate package.nix suitable for a PR in the nixpkgs repo? I'm mostly asking if I could be able to file a PR there... not sure if asking you to update version every time I release something is polite :)

(Let's ignore flakes for the moment)

Thanks!

[doronbehar]

In the ideal future, perhaps projects like this will be included in Nixpkgs via a flake reference, and not via an almost copy pasted package.nix file from here to Nixpkgs. Until then, the best thing we can do is to make this copy-paste an easy task as possible.

Hmm... so package.nix cannot go directly to the nixpkg repo since it also refers to Cargo.toml and other files in this repository?

Correct, but not only that, it's the src = self; and version attributes that need are set differently in this repo then they should be set in Nixpkgs.

Is there a semi automated way to generate package.nix suitable for a PR in the nixpkgs repo? I'm mostly asking if I could be able to file a PR there... not sure if asking you to update version every time I release something is polite :)

(Let's ignore flakes for the moment)

Thanks!

I'm not aware of such a script as you describe, but you can of course craft some automating script by yourself if you really want to. Most people don't find the need to though, as these expressions change rarely, and in any case you have to go through the Nixpkgs PR and CI process. However, if you release a new version, for simple version bumps the Nix ecosystem has a lot to offer!

The community runs a nixpkgs-update update bot that iterates all packages in Nixpkgs and updates the versions according to information it finds on GitHub, GitLab and Repology. The bot that runs it - @r-ryantm can ping you when it updates packages you maintain in Nixpkgs if you are listed as one of the maintainers of the package - see the lib/maintainers.nix file in Nixpkgs.

Additionally, if you don't want to wait for @r-ryantm, you can use nix-update python3.pkgs.pysequoia --commit while in a Nixpkgs checkout and create a PR with another tool like gh.

Hence what I'd do instead of you is create a PR in Nixpkgs with the following commits:

maintainers: add wiktor-k 
python311Packages.pysequoia: add wiktor-k as maintainer
python311Packages.pysequoia: 0.1.20 -> 0.1.22; fix darwin build # Try to use nix-update for this! Don't forget to remove the meta.broken flag

I will be requested for a review automatically by @ofborg - our CI bot runner.

[wiktor-k]

Looks great! Thanks for taking the time to explain it all to me.

As for the update please study the package.nix file as I've made some significant changes: dropped openssl and on MacOS added PCSC and removed nettle (as RustCrypto is used on that platform). It should make the package smaller :)

[doronbehar]

Looks great! Thanks for taking the time to explain it all to me.

As for the update please study the package.nix file as I've made some significant changes: dropped openssl and on MacOS added PCSC and removed nettle (as RustCrypto is used on that platform). It should make the package smaller :)

Sure! I observed everything, and it all looks good. See you in Nixpkgs 🍻 .