Feature request: new meta attr for source code repository #293838
Comments
|
There is meta.downloadPage which is documented https://github.com/NixOS/nixpkgs/blob/5bfab70cdf63ad75f1d7d0facc59fb9f49668811/doc/stdenv/meta.chapter.md#downloadpage-var-meta-downloadpage |
|
a download page and browsable source tree are entirely different things. a package that has a dedicated homepage is also very likely to have a dedicated page for downloading binaries. |
So, what? Indeed there are many times we find the opposite: the software has only the repository as its homepage. |
same logic can be applied to say that project homepages are usually designed for users, not developers, in my experience they rarely put the git repo front and center.
if you mean packages that don't have a dedicated homepage, and use the git forge instead: yes, i am well aware of that. i mention it in the original post. if you mean packages that have a dedicated homepage, and use this git forge despite this: as far as i can tell this is incorrect metadata. the homepage should point to the homepage, doing otherwise is just confusing. |
A pointer for an eye-candy webpage showing the files unpacked in the CVS? This is just eyecandy. And the CVS itself is useful for those who want to contribute or hack with the project themselves.
Yep. |
|
|
|
I've mentioned the same problem here: https://discourse.nixos.org/t/problems-regarding-meta-homepage-and-link-to-repository/39821. So thanks for raising an issue. |
The real download link is always obvious: it's in the We often do this instead: I believe the automated scripts do the same, because in this way they even don't have to parse the Nix code themselves. For package maintainers, they can read the code, and figuring out how to bump source versions shouldn't be a problem.
In fact, link to a repository is often much more useful than the This also applies to package maintainers (including the maintainer who created this package and some random people who wants to bump the package), since some dependencies are often hidden in the cmake or meson build files, some files may need to be installed manually, and some code needs to be patched to adapt to NixOS. However, unlike the
For maintainers, code modifications between version tags are far more important than the changelog, because they really directly reflect changes in dependencies and other metadata.
Users and developers are often not separate in the Linux community, especially in a distribution that requires writing code in an unfamiliar language to configure the system. It makes no sense to discuss the needs of the two in isolation.
Yes, this begs another question: What exactly is a homepage? In my opinion, a repository is a repository, while a special introduction page is a homepage. Although I did see many repositories with very detailed READMEs, and they may indeed be used as homepages, the repository itself still brings too much distraction. I would prefer that in tools like search.nixos.org, when users click on a link named "homepage" or "repository", they have clear expectations of where they will be directed. This is also a UX issue, but there may be my personal preference, and other people may have different views. |
This is a bit more complicated. The The best example: RIES! http://www.mrob.com/pub/ries/src/ries.c.txt
Many updater scripts are generated by the derivation itself. It's not the shell script that parses Nix, it's Nix code that generates the script.
Again, eye-candy for people interested in hacking/contributing to the code.
Are you seriously saying that a whole Worse, are you suggesting programmers (including but not limited to Linux kernel programmers) are so unorganized that the changelogs they wrote have zero relevance or negative reliability when compared to a machine-generated
|
I don't see what I'm saying having anything to do with hacking/contributing to the code; on the contrary, it's what you would call "normal users" doing on a daily basis.
No; for some software, the author may have a very well-written changelog, including changes in the building method; but for other projects, the diff of the build script and the addition and deletion of some special data files have provided sufficient information for package maintainers. Changes to specific functional code often do not result in package changes such as adding or removing dependencies or modifying the build process, unless a specific error is thrown in the build process.
To some extent, yes. I've seen nearly all developers who write in great detail about functional changes for their users, but there aren't that many developers who inform the build process or dependency changes for the package maintainers.
I'm not trying to please everyone. There are certainly an amount of users who will not benefit from it. But this doesn't render it useless.
But that doesn't change the unpleasant process. If we can save them time and energy, then why not?
Yes, logically they should. But what actually happens? We don't always create tools to solve a modeled problem, we also need to solve these problems in reality, especially if we happen to have the ability to do so (I mean, as shown in the PR above, some common fetchers already contain this information). |
|
Let me be the devil's advocate here. What is your goal here, by providing Will you prefer a webpage ready to be opened in a web browser, like this GitWeb interface for GCC or this mirror of GNU Emacs? Or the URL for the repo ready to be consumed by Git, like this from GCC - git://gcc.gnu.org/git/gcc.git - or this from Emacs - git.savannah.gnu.org/git/emacs.git?
|
|
@Artturin thanks, i did not know that. i would hope that automatically setting the field from src metadata would make it more useful. additionally, having a single value should make it easier for sites like search.nixos.org to use and present it. |
making drastic changes to the culture of every open source project is a lot harder than adding a few lines of code. |
i already brought up a possible solution to this in issue i submitted to nixos search: if |
Therefore you do not want the source code repository, you want a very specific eyecandy. You are naming it in a misleading way - and arguing for it in a misleading way too. The "issue tracker" of Linux kernel is a freaking mailing list. Indeed many projects still use them - hell, SourceHut was created a decade ago and they use mailing lists! Is a mailing list an acceptable value for the
Also, git allows capturing a single file since at least 1.8.
Like making all of them using GitHub exclusively? |
issue trackers exist outside of the source tree, therefore i don't want the source code repository? the issue tracker being available via the repository webpage is not a an official feature, it is simply a nice situational benefit for users.
ok, so the repository page of those projects simply won't link to the issue tracker. i don't think that's a huge deal.
no, only an http-browsable source tree is an acceptable value, as the documentation states
additional mental load of:
as opposed to just typing
what? this proposal works equally well with sites like gitea, gitlab, and SourceHut. it can even work with custom solutions like 95% of software projects have some form of http-browsable source tree, and those that don't can simply not set the field and be no worse off than if the field didn't exist. |
Then maybe instead of ‘http-browsable source tree’ being the defining characteristic of this new field, we could say that it's for homepages targeting contributors, and |
personally i think "http-browsable source tree" is much more descriptive than "homepage targeting contributors", as the latter requires making a subjective judgement on what the intended target audience of the page is (and most pages usually target both) maybe "a webpage where the package's source code can be viewed" would be easier to understand. |
I don't know, if your archetypal example is And if a project only exposes a Bugzilla instance but not an HTTP-browsable VCS, I'd still consider that to be a contributor-facing home. |
i think in that case (if it was frequent enough), we would want a separate issueTracker or bugReport field, instead of overloading the meaning of my goal with this is to make metadata easier to understand, as currently when you click the url labeled "homepage", you should go to the project's homepage, and when you click the url labeled "repository" you should go to the project's repository. |
|
Then I guess I don't know why you want this field either, given that |
|
|
Your intention is to allow only eye-candy forges or forge-like sites, and call them a generic and misleading name "repository"
Repositories that are not I have not seen such an ironic stance since the C keyword
Why such a discrimination (against
Was this an argument for or against using fetchgit?
In the worst of cases, you can grab the raw git command.
There is a thing called shell script. It can automate a tuckload of boring and forgettable tasks.
You are not targetting general-purpose repositories, but a very specific style of site.
"But only if its project's repository is an HTTP-browsable eyecandied site" - FTFY. |
don't tell me what my intention is. git.kernel.org would certainly qualify for this value, and that doesn't have any of the features you would associate with a typical forge
once again: stop telling me what i am trying to do.
i don't care about whether a webpage looks good or not. you simply decided that i did and keep asserting that i do every two sentences. it's 2024, and the world runs on http. i'm not really happy about it, but i'm not going to decrease the utility of my metadata fields out of spite. |
I don't need - you did it already: issue trackers exist outside of the source tree. they are not viewable via a git clone, but nearly every git forge links them from the repo page. Further, the whole "search engine runs on HTTP, then it can't include non-HTTP links" argument plus the examples about multiple purposes of
Then nothing hinders a Gemini link.
Are you targeting general-purpose repositories?
Then a Gemini link is acceptable, correct?
Allowing Gemini or IPFS links decrease the utility of your metadata fields? How? |
@rhendric what is the problem we just witnessed? we made a mistake fixed it and have a better implementation because of it that is immune to the previous failure. requiring a perfect first implementation is not a good faith argument. |
most packages. the entire point of testing is to catch edge cases.
well guess what, i have immediate plans for other stuff i would like to do with it so... yeah it's more that nixos-search
as already noted, doing so results in massive performance penalties.
this is simply misrepresenting my intent. i already said there are other usecases. i would really appreciate if people would stop telling me what i want. |
|
@a-n-n-a-l-e-e, I'm not requiring a perfect first implementation. The issue is that the scope increased from ‘add a field to
But you don't have to test what you don't implement! I'm really confused by our disagreement here. You want to change
How about discussing those plans then? That might convince me that implementing the feature the way you want is worth doing even if it involves changing the guarantees around
And that's much less of a big deal if it doesn't happen in the heart of Nixpkgs for everyone's evaluation.
Sorry you're frustrated, but I'm going off of what you've said in this thread so far, and I think the above comment is the first time you're mentioning any other use cases in a non-hypothetical way. |
i thought you wanted to not implement it in nixpkgs. guess what, if you move the code somewhere else, it still exists! |
|
github sucks on mobile |
This isn't the gotcha that you think it is, so the attempt at a dunk isn't exactly going to be convincing. What you would be testing if this logic were in Nixpkgs is not the correctness of the logic itself. The logic is pretty dang simple—use I'm proposing not making that change to the expectations around |
Not my intention, just an expression of surprise. For someone throwing arguments like "a lot of this was made before" without backing them up, it is hilarious that the most obvious example is now requiring evidence! |
the first one broke - twice, if you can't remember, Ghostie... |
it's really not, it's basically just nesting two for-each loops. in my experience it isn't difficult to make src eval either.
|
That'll test that it works in the specific configuration that it's tested in. But a given
Yeah, so this really comes down to a risk appetite thing. If you're a move-fast-break-things person, you might see the risk as worth it. You're looking at the things you see and saying they don't look so bad. I'm looking at the spaces where there can be things I don't see and saying why risk it? I don't think there have been enough eyeballs on this for me to feel comfortable with work that has a good chance of slipping time bombs into Hydra, which take precious time and effort to resolve. Particularly when consumers who want this logic can shoulder the burden of evaluating it themselves. Why not start there and propose moving things into Nixpkgs after you've proved the value of the work? |
so we are not trying to guarantee that src evaluates correctly. the new implementation doesn't require src to evaluate meta attributes. |
theoretically, but i don't think they're likely to in practice. anyways, by that argument, some combination of config options could cause nixpkgs as a whole to stop evaluating, since we're not testing every permutation. |
|
@a-n-n-a-l-e-e
The new implementation being #300313? Which contains this code? That's the code that doesn't require
Yes, some combination of config options could do that. I don't know what point you're trying to make with that statement. |
right. |
this is another assumption that can be broken easily.
(currently I am more inclined to an "outside nix" approach (scripting, manual fixup, treewide, small steps), in case someone asks me.) |
unless you are using import-from-derivation (which is banned in nixpkgs), assembly will never be interpreted at eval time, only at build time.
font glyphs are binary data, not binary code. it could be argued that truetype fonts contain vm bytecode, but they certainly do not contain native code. |
|
so i wanted to see how many aborts are generated from trying script.sh#!/usr/bin/env bash
# https://github.com/NixOS/ofborg?tab=readme-ov-file#running-meta-checks-locally
curl -OL https://raw.githubusercontent.com/NixOS/ofborg/released/ofborg/src/outpaths.nix
GC_INITIAL_HEAP_SIZE=4g nix-env -f ./outpaths.nix -qaP --no-name --out-path --arg checkMeta true > out-paths
# transform out-paths to:
# pkgs: with pkgs; [
# pkg-name.meta.repository or null
# ...
# ]
# need to remove packages with names that include '+' and .if. and pkgs-lib-tests
cat out-paths | \
gawk '{gsub("\\.[^.]*$", ".meta.repository or null", $1); print $1}' | \
sort -u | \
sed -e '/haskellPackages.if/d' \
-e '/pkgs-lib-tests/d' \
-e '/+/d' | \
awk 'BEGIN{ print "pkgs: with pkgs; ["}
{ print $0 }
END{ print "]"}' > out-paths.nix
for sys in x86_64-darwin x86_64-linux aarch64-darwin aarch64-linux; do
nix eval --impure --expr 'with import ./. { system = '"\"$sys\""'; }; map (t: builtins.tryEval t) ((import ./out-paths.nix) pkgs)'
donenixpkgs.diff add repository to meta and add throw to 19 filesdiff --git a/pkgs/applications/audio/renoise/default.nix b/pkgs/applications/audio/renoise/default.nix
index d3462ecc6ad5..a56d43876fb0 100644
--- a/pkgs/applications/audio/renoise/default.nix
+++ b/pkgs/applications/audio/renoise/default.nix
@@ -39,7 +39,7 @@ in stdenv.mkDerivation rec {
releasePath
else
let
- platform = platforms.${stdenv.system};
+ platform = platforms.${stdenv.system} or (throw "unsupported system ${stdenv.hostPlatform.system}");
urlVersion = lib.replaceStrings [ "." ] [ "_" ] version;
in fetchurl {
url =
diff --git a/pkgs/applications/gis/udig/default.nix b/pkgs/applications/gis/udig/default.nix
index 8510918d4cab..264445336cd3 100644
--- a/pkgs/applications/gis/udig/default.nix
+++ b/pkgs/applications/gis/udig/default.nix
@@ -13,7 +13,7 @@ let
hash = "sha256-Ihk3InHB3/tEYRqH2ozhokz2GN8Gfig5DJkO/8P1LJs=";
};
};
- src = srcs.${stdenv.hostPlatform.system};
+ src = srcs.${stdenv.hostPlatform.system} or (throw "unsupported system ${stdenv.hostPlatform.system}");
meta = with lib; {
description = "User-friendly Desktop Internet GIS";
diff --git a/pkgs/applications/graphics/sane/backends/brscan4/default.nix b/pkgs/applications/graphics/sane/backends/brscan4/default.nix
index ec8efcc27c2a..c15b3033a265 100644
--- a/pkgs/applications/graphics/sane/backends/brscan4/default.nix
+++ b/pkgs/applications/graphics/sane/backends/brscan4/default.nix
@@ -21,7 +21,7 @@ stdenv.mkDerivation rec {
url = "https://download.brother.com/welcome/dlf006645/${pname}-${version}.amd64.deb";
sha256 = "sha256-Gpr5456MCNpyam3g2qPo7S3aEZFMaUGR8bu7YmRY8xk=";
};
- }."${stdenv.hostPlatform.system}";
+ }."${stdenv.hostPlatform.system}" or (throw "unsupported system ${stdenv.hostPlatform.system}");
unpackPhase = ''
ar x $src
diff --git a/pkgs/applications/misc/1password-gui/default.nix b/pkgs/applications/misc/1password-gui/default.nix
index 32825d3ba523..5a7e4914f8cd 100644
--- a/pkgs/applications/misc/1password-gui/default.nix
+++ b/pkgs/applications/misc/1password-gui/default.nix
@@ -51,7 +51,7 @@ let
};
src = fetchurl {
- inherit (sources.${channel}.${stdenv.system}) url hash;
+ inherit (sources.${channel}.${stdenv.system} or (throw "unsupported system ${stdenv.hostPlatform.system}")) url hash;
};
meta = with lib; {
diff --git a/pkgs/applications/networking/cluster/hadoop/default.nix b/pkgs/applications/networking/cluster/hadoop/default.nix
index d5bae9ad885b..5f44e39d008c 100644
--- a/pkgs/applications/networking/cluster/hadoop/default.nix
+++ b/pkgs/applications/networking/cluster/hadoop/default.nix
@@ -35,7 +35,7 @@ let
src = fetchurl {
url = "mirror://apache/hadoop/common/hadoop-${finalAttrs.version}/hadoop-${finalAttrs.version}"
+ optionalString stdenv.isAarch64 "-aarch64" + ".tar.gz";
- inherit (platformAttrs.${stdenv.system}) hash;
+ inherit (platformAttrs.${stdenv.system} or (throw "Unsupported system: ${stdenv.system}")) hash;
};
doCheck = true;
diff --git a/pkgs/applications/networking/instant-messengers/discord/default.nix b/pkgs/applications/networking/instant-messengers/discord/default.nix
index 40e9c77e57a7..423f6cb2f1db 100644
--- a/pkgs/applications/networking/instant-messengers/discord/default.nix
+++ b/pkgs/applications/networking/instant-messengers/discord/default.nix
@@ -52,7 +52,7 @@ let
};
aarch64-darwin = x86_64-darwin;
};
- src = srcs.${stdenv.hostPlatform.system}.${branch};
+ src = srcs.${stdenv.hostPlatform.system}.${branch} or (throw "${stdenv.hostPlatform.system} not supported on ${branch}");
meta = with lib; {
description = "All-in-one cross-platform voice and text chat for gamers";
diff --git a/pkgs/applications/science/electronics/picoscope/default.nix b/pkgs/applications/science/electronics/picoscope/default.nix
index c7242117b68c..3aa5cb22aa52 100644
--- a/pkgs/applications/science/electronics/picoscope/default.nix
+++ b/pkgs/applications/science/electronics/picoscope/default.nix
@@ -49,7 +49,7 @@ let
# If we don't have a platform available, put a dummy version here, so at
# least evaluation succeeds.
sources =
- (lib.importJSON ./sources.json).${stdenv.system} or { picoscope.version = "unknown"; };
+ (lib.importJSON ./sources.json).${stdenv.system} or (throw "unsupported system ${stdenv.system}");
scopePkg = name:
{ url, version, sha256 }:
diff --git a/pkgs/applications/version-management/radicle-upstream/default.nix b/pkgs/applications/version-management/radicle-upstream/default.nix
index 97fec6257dd1..69c960ed78e8 100644
--- a/pkgs/applications/version-management/radicle-upstream/default.nix
+++ b/pkgs/applications/version-management/radicle-upstream/default.nix
@@ -15,7 +15,7 @@ let
sha256 = "sha256-EuWGbn6qggi8/9Rci8iaXfuVKE+QXb1BHEYDvotR/q4=";
};
};
- src = srcs.${stdenv.hostPlatform.system};
+ src = srcs.${stdenv.hostPlatform.system} or (throw "unsupported system ${stdenv.hostPlatform.system}");
contents = appimageTools.extract { inherit name src; };
diff --git a/pkgs/applications/virtualization/firecracker/default.nix b/pkgs/applications/virtualization/firecracker/default.nix
index d9bab2169623..2c3ec6c9a75b 100644
--- a/pkgs/applications/virtualization/firecracker/default.nix
+++ b/pkgs/applications/virtualization/firecracker/default.nix
@@ -13,7 +13,7 @@ let
dlbin = sha256: fetchurl {
url = "${baseurl}/v${version}/firecracker-v${version}-${suffix}.tgz";
- sha256 = sha256."${stdenv.hostPlatform.system}";
+ sha256 = sha256."${stdenv.hostPlatform.system}"or (throw "unsupported system ${stdenv.hostPlatform.system}");
};
in
diff --git a/pkgs/development/compilers/oraclejdk/jdk-linux-base.nix b/pkgs/development/compilers/oraclejdk/jdk-linux-base.nix
index 40681faae8ae..d03419e96570 100644
--- a/pkgs/development/compilers/oraclejdk/jdk-linux-base.nix
+++ b/pkgs/development/compilers/oraclejdk/jdk-linux-base.nix
@@ -80,7 +80,7 @@ let result = stdenv.mkDerivation rec {
in requireFile {
name = "jdk-${productVersion}u${patchVersion}-${platformName}.tar.gz";
url = "http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html";
- sha256 = sha256.${stdenv.hostPlatform.system};
+ sha256 = sha256.${stdenv.hostPlatform.system} or (throw "unsupported system ${stdenv.hostPlatform.system}");
};
nativeBuildInputs = [ file makeWrapper ]
diff --git a/pkgs/development/compilers/temurin-bin/jdk-darwin-base.nix b/pkgs/development/compilers/temurin-bin/jdk-darwin-base.nix
index 14871813273d..8f6831a7907c 100644
--- a/pkgs/development/compilers/temurin-bin/jdk-darwin-base.nix
+++ b/pkgs/development/compilers/temurin-bin/jdk-darwin-base.nix
@@ -24,7 +24,7 @@ let
sourcePerArch.${cpuName}.version or (throw "unsupported CPU ${cpuName}");
src = fetchurl {
- inherit (sourcePerArch.${cpuName}) url sha256;
+ inherit (sourcePerArch.${cpuName} or (throw "unsupported system ${stdenv.hostPlatform.system}")) url sha256;
};
# See: https://github.com/NixOS/patchelf/issues/10
diff --git a/pkgs/development/libraries/libcef/default.nix b/pkgs/development/libraries/libcef/default.nix
index d6d098110af8..ce83c3c22cd4 100644
--- a/pkgs/development/libraries/libcef/default.nix
+++ b/pkgs/development/libraries/libcef/default.nix
@@ -73,7 +73,7 @@ let
platforms."aarch64-linux".sha256 = "16sbfk599h96wcsmpbxlwsvq0n1pssmm8dpwmjsqfrn1464dvs68";
platforms."x86_64-linux".sha256 = "1wa4nv28saz96kar9svdarfz6c4rnbcqz0rqxzl9zclnhfzhqdiw";
- platformInfo = builtins.getAttr stdenv.hostPlatform.system platforms;
+ platformInfo = platforms.${stdenv.hostPlatform.system} or (throw "unsupported system ${stdenv.hostPlatform.system}");
in
stdenv.mkDerivation rec {
pname = "cef-binary";
diff --git a/pkgs/development/tools/azure-static-sites-client/default.nix b/pkgs/development/tools/azure-static-sites-client/default.nix
index 08e56de7335b..452976b7282a 100644
--- a/pkgs/development/tools/azure-static-sites-client/default.nix
+++ b/pkgs/development/tools/azure-static-sites-client/default.nix
@@ -21,7 +21,7 @@ let
};
sources = {
"x86_64-linux" = fetchBinary "linux-x64";
- "x86_64-darwin" = fetchBinary "macOS";
+ "x86_64-darwin" = fetchBinary "osx-x64";
};
in
stdenv.mkDerivation {
diff --git a/pkgs/servers/meteor/default.nix b/pkgs/servers/meteor/default.nix
index 0ce2189568cb..7830d309b082 100644
--- a/pkgs/servers/meteor/default.nix
+++ b/pkgs/servers/meteor/default.nix
@@ -20,7 +20,7 @@ in
stdenv.mkDerivation {
inherit version;
pname = "meteor";
- src = srcs.${system};
+ src = srcs.${system} or (throw "unsupported system ${system}");
#dontStrip = true;
diff --git a/pkgs/stdenv/generic/check-meta.nix b/pkgs/stdenv/generic/check-meta.nix
index 1cd1ae6dd72e..f1f486b115a8 100644
--- a/pkgs/stdenv/generic/check-meta.nix
+++ b/pkgs/stdenv/generic/check-meta.nix
@@ -10,7 +10,9 @@ let
concatMapStrings
concatMapStringsSep
concatStrings
+ filter
findFirst
+ head
isDerivation
length
concatMap
@@ -39,6 +41,11 @@ let
toPretty
;
+ unlist = list:
+ if length list == 1
+ then head list
+ else list;
+
# If we're in hydra, we can dispense with the more verbose error
# messages and make problems easier to spot.
inHydra = config.inHydra or false;
@@ -303,6 +310,10 @@ let
(listOf str)
str
];
+ repository = union [
+ (listOf str)
+ str
+ ];
downloadPage = str;
changelog = union [
(listOf str)
@@ -452,8 +463,14 @@ let
let
outputs = attrs.outputs or [ "out" ];
hasOutput = out: builtins.elem out outputs;
- in
- {
+ in {
+ repository =
+ if attrs ? src.meta.homepage
+ then attrs.src.meta.homepage
+ else if attrs ? srcs && isList attrs.srcs
+ then unlist (map (src: src.meta.homepage) (filter (src: src ? meta.homepage) attrs.srcs))
+ else [];
+
# `name` derivation attribute includes cross-compilation cruft,
# is under assert, and is sanitized.
# Let's have a clean always accessible version here.
diff --git a/pkgs/tools/archivers/rar/default.nix b/pkgs/tools/archivers/rar/default.nix
index 3799afd736ef..fabcfde887e0 100644
--- a/pkgs/tools/archivers/rar/default.nix
+++ b/pkgs/tools/archivers/rar/default.nix
@@ -37,7 +37,7 @@ stdenv.mkDerivation {
pname = "rar";
inherit version;
- src = fetchurl (srcs.${stdenv.hostPlatform.system});
+ src = fetchurl (srcs.${stdenv.hostPlatform.system} or (throw "unsupported system ${stdenv.hostPlatform.system}"));
dontBuild = true;
diff --git a/pkgs/tools/misc/geekbench/5.nix b/pkgs/tools/misc/geekbench/5.nix
index 7784b3632a73..49efe2ea0bf9 100644
--- a/pkgs/tools/misc/geekbench/5.nix
+++ b/pkgs/tools/misc/geekbench/5.nix
@@ -26,7 +26,7 @@ stdenv.mkDerivation {
inherit version;
pname = "geekbench";
- src = fetchurl (sources.${stdenv.system});
+ src = fetchurl (sources.${stdenv.system} or (throw "unsupported system ${stdenv.hostPlatform.system}"));
dontConfigure = true;
dontBuild = true;
diff --git a/pkgs/tools/misc/geekbench/6.nix b/pkgs/tools/misc/geekbench/6.nix
index 4ac5f1d0e49a..373d93dc193c 100644
--- a/pkgs/tools/misc/geekbench/6.nix
+++ b/pkgs/tools/misc/geekbench/6.nix
@@ -27,7 +27,7 @@ stdenv.mkDerivation {
inherit version;
pname = "geekbench";
- src = fetchurl (sources.${stdenv.system});
+ src = fetchurl (sources.${stdenv.system} or (throw "unsupported system ${stdenv.hostPlatform.system}"));
dontConfigure = true;
dontBuild = true;
diff --git a/pkgs/tools/misc/hakuneko/default.nix b/pkgs/tools/misc/hakuneko/default.nix
index 0ad8c5907a70..0359da603ccb 100644
--- a/pkgs/tools/misc/hakuneko/default.nix
+++ b/pkgs/tools/misc/hakuneko/default.nix
@@ -36,7 +36,7 @@ stdenv.mkDerivation rec {
url = "https://github.com/manga-download/hakuneko/releases/download/v${version}/hakuneko-desktop_${version}_linux_i386.deb";
sha256 = "32017d26bafffaaf0a83dd6954d3926557014af4022a972371169c56c0e3d98b";
};
- }."${stdenv.hostPlatform.system}";
+ }."${stdenv.hostPlatform.system}" or (throw "unsupported system ${stdenv.hostPlatform.system}");
dontBuild = true;
dontConfigure = true;
diff --git a/pkgs/tools/security/sonar-scanner-cli/default.nix b/pkgs/tools/security/sonar-scanner-cli/default.nix
index 553019299ba7..b97a2bc3a105 100644
--- a/pkgs/tools/security/sonar-scanner-cli/default.nix
+++ b/pkgs/tools/security/sonar-scanner-cli/default.nix
@@ -19,7 +19,7 @@ in stdenv.mkDerivation rec {
inherit version;
pname = "sonar-scanner-cli";
- src = fetchurl sonarScannerArchPackage.${stdenv.hostPlatform.system};
+ src = fetchurl sonarScannerArchPackage.${stdenv.hostPlatform.system} or (throw "unsupported system ${stdenv.hostPlatform.system}");
nativeBuildInputs = [ unzip ];
[edit] opened PRs to change aborts to throw (and fix a typo) |
Irrelevant. There is nothing hindering someone to write code like "throw when host is not x86" when facing a
Data-code distinction lose most of its explanatory power since before the first worm, passing through undergrounds like Forth, Lisp and Phrack, and nowadays with the dreadful xzdoor. Further it misses the point I tried to convey: a non- Nonetheless my catastrophic example does not affect the argument: neither |
a throw error would be fine, actually. it would be caught by a tryEval in release-attrpaths-superset calling abort would not be fine, and would probably cause CI to fail. the only exceptions i know are calling so... don't do that? |
You don't know that. Current usage can include I'm fine with #300286 but I think any PR that makes |
|
This issue has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/when-should-meta-attributes-be-computed/42833/1 |
if that is a usage we want to support then it should have a CI test. |
Problem
most packages use
meta.homepageto link to the source code repository, but for projects with an actual homepage (such as luajit), finding the source code often requires clicking around various links to try to find the official repo.for packages that use
fetchFromGitHubor similar, you can usually piece the url back together with some effort, but for projects that use a source tarball (again, like luajit), you're out of luck.Proposal
a
meta.repositoryfield that points to an http-browsable source tree.for packages without a separate homepage, you could just set the
meta.repositoryfield instead.Checklist
Add a 👍 reaction to issues you find important.
The text was updated successfully, but these errors were encountered: