cc @globin .

@doronbehar Are you able to merge this? 👍
Or is it blocked by something I can look into?

Switched to fetchFromGitLab in all plugin projects.

Why?

@doronbehar Are you able to merge this? 👍
Or is it blocked by something I can look into?

No, I don't have merge permissions.

Switched to fetchFromGitLab in all plugin projects.

Why?

Well, in the past they had some issues with their GitLab instance. Now they don't, and it seems like a more official source to me, compared to that GitHub mirror. If you strongly think I should revert it, I'll do it.

Why?

Well, in the past they had some issues with their GitLab instance. Now they don't, and it seems like a more official source to me, compared to that GitHub mirror. If you strongly think I should revert it, I'll do it.

I was mostly wondering about the tarballs downloaded with fetchurl like
https://pwmt.org/projects/zathura/plugins/download/${name}.tar.xz
Each plugin has a page with tarball hashes (e.g. [1]). Those should be more stable than GitLab tarballs.

[1] https://pwmt.org/projects/zathura-pdf-poppler/download/

Each plugin has a page with tarball hashes (e.g. [1]). Those should be more stable than GitLab tarballs.

I agree that using upstream's hashes is awesome, but I tend to like the idea of using fetchFromGitLab vs fetchurl because automatic updates (not yet implemented) could use that to automatically check for new updates. I'm planning my self to work on this in the summer.

I agree that using upstream's hashes is awesome, but I tend to like the idea of using fetchFromGitLab vs fetchurl because automatic updates (not yet implemented) could use that to automatically check for new updates. I'm planning my self to work on this in the summer.

In this case, it would not be possible to reuse upstream hashes because nix doesn't support SHA2. The way I see it, using the released tarballs should provide a better long term reproducibility. The other problem with fetchGitLab in zathura is that despite it using fetchurl under the hood, its tarballs can not be mirrored by the tarballs.nixos.org, as it appears:

nix-repl> import <nixpkgs/maintainers/scripts/find-tarballs.nix> { expr = (import <nixpkgs> {}).zathura; }  
[ ]

I think your idea of having faster than repology updates will hit this issue as well and it would require a major refactoring of how zathura is defined. So, I think, we better use the stable tarballs where possible for now and leave the refactoring for a separate PR.

addition: after writing this, I found out that I made few mistakes here: 1) fetchGitLab is based on fetchzip and not fetchurl 2) I was evaluating zathura on x86_64-drawin, this is why the list is empty, for correct evaluation see my next message

@veprbl I'm not sure I've managed to follow. So I'll address all my misunderstandings here:

@doronbehar Here is a zathura_core attribute (inside a private scope):

What was the original motive / reason for which you suggested to change the attribute to zathura?

In this case, it would not be possible to reuse upstream hashes because nix doesn't support SHA2.

So we (almost) always use sha256 and upstream uses sha-2 - I understand why that idea of using upstream's hashes is irrelevant 👍 . But I don't understand what makes these tarballs as more reproducible.

The way I see it, using the released tarballs should provide a better long term reproducibility.

You mean it'll be more reproducible because:

its tarballs can not be mirrored by the tarballs.nixos.org.

?

I think your idea of having faster than repology updates will hit this issue as well and it would require a major refactoring of how zathura is defined. So, I think, we better use the stable tarballs where possible for now and leave the refactoring for a separate PR.

I'm didn't refer to "faster than repology updates", I only meant I intend to contribute to the repology project by parsing nixpkgs for derivations that use fetchFromGitHub (or GitLab) and update the latest version (in repology) according to the latest release - without waiting for another distro to do it. Hence I don't see how using fetchurl vs fetchFromGitLab introduces a major refactoring.

What was the original motive / reason for which you suggested to change the attribute to zathura?

You've changed the value of zathura_core.pname from "zathura-core" to "zathura". It would make sense to also rename the attribute zathura_core to zathura for consistency.

But I don't understand what makes these tarballs as more reproducible.

The tarballs generated by GitLab are not stored on disks and not backed up. The hashes may change with new version of GitLab or with a switch to another service.

Another reason why the released tarballs are more "reproducible" is because fetched with fetchurl and can be discovered maintainers/scripts/all-tarballs.nix to be mirrored on tarballs.nixos.org. This is not true for the fetchFromGitLab because it uses fetchzip under the hood, which is also a fixed-output derivation, but it's put into the store as an unpacked directory. But we only mirror "flat" tarballs:

# echo '(import ./. {}).zathura.name' | nix repl | grep zathura
"zathura-with-plugins-0.4.4"

# echo ':p import ./maintainers/scripts/find-tarballs.nix { expr = (import ./. {}).zathura; }' | nix repl | tr '}' '\n' | grep pwmt
[ { hash = "0v5klgr009rsxi41h73k0398jbgmgh37asvwz2w15i4fzmw89jgb"; name = "zathura-0.4.4.tar.gz"; type = "sha256"; url = "https://git.pwmt.org/pwmt/zathura/-/archive/0.4.4/zathura-0.4.4.tar.gz"; 
 { hash = "08zdsr4zwi49facsl5596l0g1xqqv2jk3sqk841gkxwawcggim44"; name = "girara-0.3.4.tar.gz"; type = "sha256"; url = "https://git.pwmt.org/pwmt/girara/-/archive/0.3.4/girara-0.3.4.tar.gz"; 

But after your change they are not (you don't adjust girara):

# echo '(import ./. {}).zathura.name' | nix repl | grep zathura
"zathura-with-plugins-0.4.5"

# echo ':p import ./maintainers/scripts/find-tarballs.nix { expr = (import ./. {}).zathura; }' | nix repl | tr '}' '\n' | grep pwmt
 { hash = "08zdsr4zwi49facsl5596l0g1xqqv2jk3sqk841gkxwawcggim44"; name = "girara-0.3.4.tar.gz"; type = "sha256"; url = "https://git.pwmt.org/pwmt/girara/-/archive/0.3.4/girara-0.3.4.tar.gz"; 

So my problem with your change is that you switch away from the stable tarballs and remove the possibility for tarballs to be archived on tarballs.nixos.org.

Hence I don't see how using fetchurl vs fetchFromGitLab introduces a major refactoring.

If you look at my outputs above, you may notice that the plugin tarballs are missing. This is because the find-tarballs.nix has another flaw which it that it doesn't inspect context for strings. I thought this would require a major refactoring to work this around, but it can be also a hack like this:

diff --git a/pkgs/applications/misc/zathura/wrapper.nix b/pkgs/applications/misc/zathura/wrapper.nix
index 6c8ad97d355..a97138d4a1a 100644
--- a/pkgs/applications/misc/zathura/wrapper.nix
+++ b/pkgs/applications/misc/zathura/wrapper.nix
@@ -10,6 +10,7 @@ in symlinkJoin {
 
   buildInputs = [ makeWrapper ];
 
+  inherit plugins;
   postBuild = ''
     makeWrapper ${zathura_core.bin}/bin/zathura $out/bin/zathura \
       --prefix PATH ":" "${lib.makeBinPath [ file ]}" \

I think, this change need to be applied to the zathura.

... But we only mirror "flat" tarballs

I wonder what that is..

So my problem with your change is that you switch away from the stable tarballs and remove the possibility for tarballs to be archived on tarballs.nixos.org.

OK, I guess there I'll be able to find other ways for my future repology improvement to check for new releases via their GitLab instance.

What was the original motive / reason for which you suggested to change the attribute to zathura?

You've changed the value of zathura_core.pname from "zathura-core" to "zathura". It would make sense to also rename the attribute zathura_core to zathura for consistency.

My opinion is not that strong regarding this, it's just that usually, (see neovim's wrapped and unwrapped derivations) there's a different suffix for the attribute of the wrapped and the unwrapped derivation. E,g to access neovim's unwrapped derivation - you can do it with neovim.unwrapped (implemented via passthru) and with neovim-unwrapped.