Feature request: new meta attr for source code repository

[lolbinarycat]

Problem

most packages use meta.homepage to 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 fetchFromGitHub or 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.repository field that points to an http-browsable source tree.

for packages without a separate homepage, you could just set the meta.repository field instead.

Checklist

• checked latest Nixpkgs manual (source) and latest NixOS manual (source)
• checked open documentation issues for possible duplicates
• checked open documentation pull requests for possible solutions

---

Add a 👍 reaction to issues you find important.

[SuperSandro2000]

There is meta.downloadPage which is documented https://github.com/NixOS/nixpkgs/blob/5bfab70cdf63ad75f1d7d0facc59fb9f49668811/doc/stdenv/meta.chapter.md#downloadpage-var-meta-downloadpage

[lolbinarycat]

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.

[AndersonTorres]

most packages use meta.homepage to 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.

So, what?
This is a decision from the upstream maintainers to not provide an easy link to their CVS repos.
Ask them for an easier-to-find link.

Indeed there are many times we find the opposite: the software has only the repository as its homepage.
E.g. I keep bqn-mode in github and never set a dedicated homepage for it.

[lolbinarycat]

This is a decision from the upstream maintainers to not provide an easy link to their CVS repos.
Ask them for an easier-to-find link.

same logic can be applied to say that meta.downloadPage and meta.changelog shouldn't exist.

project homepages are usually designed for users, not developers, in my experience they rarely put the git repo front and center.

Indeed there are many times we find the opposite: the software has only the repository as its homepage.
E.g. I keep bqn-mode in github and never set a dedicated homepage for it.

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.

[AndersonTorres]

same logic can be applied to say that meta.downloadPage and meta.changelog shouldn't exist.

meta.downloadPage is useful when the download page is wildly different from the homepage.
That's useful for automated scripts.

meta.changelog has useful info for package maintainers.

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.
For a package maintainer, this is just downloadPage, albeit it is not an adequate name.

project homepages are usually designed for users, not developers

Yep.
Convince them we programmers are more important than those mere users...

[Artturin]

meta.repositories used to exist but was removed in 33cce15

[Aleksanaa]

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.

[Aleksanaa]

meta.downloadPage is useful when the download page is wildly different from the homepage. That's useful for automated scripts.

The real download link is always obvious: it's in the src field. This excludes a small number of packages with a download link hidden behind the paywall. But in this case, downloadPage is still useless for automated scripts or package maintainers. In fact, not a large proportion of software packages really use downloadPage.

We often do this instead:

nix-repl> :l <nixpkgs>

nix-repl> pkgs.mailspring.src.url 
"https://github.com/Foundry376/Mailspring/releases/download/1.13.3/mailspring-1.13.3-amd64.deb"

nix-repl> pkgs.go-musicfox.src.url 
"https://github.com/go-musicfox/go-musicfox/archive/v4.3.1.tar.gz"

nix-repl> pkgs.transmission.src.url
"https://github.com/transmission/transmission.git"

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.

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.
For a package maintainer, this is just downloadPage, albeit it is not an adequate name.

In fact, link to a repository is often much more useful than the downloadPage. We can roughly observe whether this project is in a good development state (I will not define this term here, it is related to the user's personal needs). On third-party code hosting platforms, we can often find the issue area in a fixed location (rather than a random place), so that we can have a general understanding of the quality of the program, submit issues, or find workarounds to known problems.

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 downloadPage, sometimes we are not using the src related to the repository (such as mirror, upstream deb package, or simply download link not including the repo)

meta.changelog has useful info for package maintainers.

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.

Convince them we programmers are more important than those mere users...

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.

Indeed there are many times we find the opposite: the software has only the repository as its homepage.

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.

[AndersonTorres]

The real download link is always obvious: it's in the src field.

This is a bit more complicated. The src field does not necessarily tells us what is the newest release.
There are some wackos that use the same link and didn't even provide a versioned tarball.

The best example: RIES!

http://www.mrob.com/pub/ries/src/ries.c.txt

I believe the automated scripts do the same, because in this way they even don't have to parse the Nix code themselves.

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.

On third-party code hosting platforms, we can often find the issue area in a fixed location (rather than a random place), so that we can have a general understanding of the quality of the program, submit issues, or find workarounds to known problems.

Again, eye-candy for people interested in hacking/contributing to the code.

meta.changelog has useful info for package maintainers.

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.

Are you seriously saying that a whole diff -Naur between two releases of Linux kernel, with nothing else, is way more important than the changelog the kernel developers wrote?

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 diff -Naur?

Users and developers are often not separate in the Linux community

1. Often not is not the same as never.
2. Usually programmers are smarter than users, and smart enough to figure themselves by being very keen to look for some keywords such as “star”, “contribute”, “submit an issue”, or “development”, or find the GitHub icon in the sidebar.
   1. This is especially true about the users of a distribution that requires writing code in an unfamiliar language to configure the system (Bash?).
3. It does not change the argument: the upstream webmasters should provide an easier-to-find link for their VCSes to begin with, not the package managers.

[Aleksanaa]

On third-party code hosting platforms, we can often find the issue area in a fixed location (rather than a random place), so that we can have a general understanding of the quality of the program, submit issues, or find workarounds to known problems.

Again, eye-candy for people interested in hacking/contributing to the code.

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.

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.

Are you seriously saying that a whole diff -Naur between two releases of Linux kernel, with nothing else, is way more important than the changelog the kernel developers wrote?

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.

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 diff -Naur?

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.

Users and developers are often not separate in the Linux community

1. Often not is not the same as never.

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.

2. Usually programmers are smarter than users, and smart enough to figure themselves by being very keen to look for some keywords such as “star”, “contribute”, “submit an issue”, or “development”, or find the GitHub icon in the sidebar.

But that doesn't change the unpleasant process. If we can save them time and energy, then why not?

3. It does not change the argument: the upstream webmasters should provide an easier-to-find link for their VCSes to begin with, not the package managers.

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).