# Is there a way to get the description of a \*package\*, rather than the software it contains?
**URL:** https://discourse.nixos.org/t/is-there-a-way-to-get-the-description-of-a-package-rather-than-the-software-it-contains/46742
**Category:** Help
**Created:** [June 9, 2024, 3:01am UTC](https://discourse.nixos.org/t/is-there-a-way-to-get-the-description-of-a-package-rather-than-the-software-it-contains/46742 "2024-06-09T03:01:25Z")
**Posts on this page:** 10
**Page:** 1
### Author:  [@535](https://discourse.nixos.org/u/535)
#### Post date: [June 9, 2024, 3:01am UTC](https://discourse.nixos.org/t/is-there-a-way-to-get-the-description-of-a-package-rather-than-the-software-it-contains/46742/1 "2024-06-09T03:01:25Z")
The motivating example for this issue is Git.
I’m trying out NixOS in a VM, saw that Git isn’t installed by default, and went straight to [the package search](https://search.nixos.org/packages?channel=24.05&type=packages&query=git). Sure enough, there are four different packages which provide `git`… but they all have the same description:
> Distributed version control system
>
> Git, a popular distributed version control system designed to handle very large projects with speed and efficiency.
The package names provide some basic information (“gitMinimal” → “git” → “gitFull” is pretty clear), but don’t really provide any detail about the differences between them. I could read [the Nix source for the packages](https://github.com/NixOS/nixpkgs/blob/9b5328b7f761a7bbdc0e332ac4cf076a3eedb89b/pkgs/applications/version-management/git/default.nix) to get the details with enough effort, but that sounds like an _exhausting_ amount of research to do for more than a handful of packages, especially when I’m only starting out with Nix. 😭
Is there a way to learn about the _Nix packages_ themselves (for example, how they differ from similar ones) rather than the _software packages_ they contain?
---
### Author:  [@anon20203487](https://discourse.nixos.org/u/anon20203487)
#### Post date: [June 9, 2024, 3:55am UTC](https://discourse.nixos.org/t/is-there-a-way-to-get-the-description-of-a-package-rather-than-the-software-it-contains/46742/2 "2024-06-09T03:55:31Z")
Problem is, sometimes a same Nix file is used to generate various packages.
Git is such an example: if you click, they will point to the same file at Nixpkgs.
All those Gits are more or less the same, differing in the options.
If I understood you correctly, the way would be editing the meta.description, like we do with Emacs Mainline vs Macport.
---
### Author:  [@rhendric](https://discourse.nixos.org/u/rhendric)
#### Post date: [June 9, 2024, 4:36am UTC](https://discourse.nixos.org/t/is-there-a-way-to-get-the-description-of-a-package-rather-than-the-software-it-contains/46742/3 "2024-06-09T04:36:28Z")
Some packages have a `meta.description` that varies based on the package arguments. That might be the optimal way to deal with some of these variants, because it puts all the description logic in one place.
Other packages, like the `git` series, have a lot of switches that can be toggled on or off, and for those cases maybe it would be better to hand-craft descriptions in `top-level.nix` instead of generating them in the package file:
> `gitFull`: This package includes all optional features, including support for SVN, SSH, sending emails, and a GUI.
> `gitSVN`: Relative to `git`, this package adds SVN support.
> `gitMinimal`: Relative to `git`, this package excludes a manual and integration with Perl, Python, and PCRE.
I know of no packages that do this, though. Maybe we should create another `override` variant, `overrideWithDescription`, that accepts a string argument in addition to the new args attrset, and appends that string to `meta.description` or `meta.longDescription`.
---
### Author:  [@doronbehar](https://discourse.nixos.org/u/doronbehar)
#### Post date: [June 9, 2024, 6:28am UTC](https://discourse.nixos.org/t/is-there-a-way-to-get-the-description-of-a-package-rather-than-the-software-it-contains/46742/4 "2024-06-09T06:28:43Z")
I agree with @rhendric’s comment, and I think that this could be another motivation and usecase for a mini module system for packages, such as introduced [here](https://github.com/NixOS/nixpkgs/pull/312432).
---
### Author:  [@Atemu](https://discourse.nixos.org/u/Atemu)
#### Post date: [June 9, 2024, 1:35pm UTC](https://discourse.nixos.org/t/is-there-a-way-to-get-the-description-of-a-package-rather-than-the-software-it-contains/46742/5 "2024-06-09T13:35:14Z")
Not sure what a mini-module system would solve here as this is about conveying what the defaults mean in a more abstract sense which I think can only be done through manual documentation.
---
### Author:  [@doronbehar](https://discourse.nixos.org/u/doronbehar)
#### Post date: [June 9, 2024, 3:16pm UTC](https://discourse.nixos.org/t/is-there-a-way-to-get-the-description-of-a-package-rather-than-the-software-it-contains/46742/6 "2024-06-09T15:16:44Z")
I was thinking about this: If every build option has a description in the module system, we can put make the module system put this information in the `meta.longDescription` automatically. For example for the git variants, the long description could get appended:
```plaintext
Enabled features:
- svn: support bidirectional operations between a Subversion repository and Git
- ssh: support advanced ssh operations (made this one up)
- email: support git commands that send emails
...
Disabled features:
- perl: support perl based git- utilities
...
```
---
### Author:  [@535](https://discourse.nixos.org/u/535)
#### Post date: [June 9, 2024, 7:43pm UTC](https://discourse.nixos.org/t/is-there-a-way-to-get-the-description-of-a-package-rather-than-the-software-it-contains/46742/7 "2024-06-09T19:43:06Z")
@rhendric, that level of detail would be perfect to display by default, IMO.
@doronbehar, the exact set of enabled/disabled features (when applicable) would be great as an additional level of detail, too.
---
### Author:  [@abathur](https://discourse.nixos.org/u/abathur)
#### Post date: [June 9, 2024, 9:09pm UTC](https://discourse.nixos.org/t/is-there-a-way-to-get-the-description-of-a-package-rather-than-the-software-it-contains/46742/8 "2024-06-09T21:09:17Z")
Some features are os/system-conditional–if we were just trying to enumerate these in some interface we’d probably end up with rough edges around either having:
- a number of platform-specific descriptions
- descriptions that ~lie about some feature being enabled if you aren’t on the platform the description was evaluated on
---
### Author:  [@rhendric](https://discourse.nixos.org/u/rhendric)
#### Post date: [June 9, 2024, 10:36pm UTC](https://discourse.nixos.org/t/is-there-a-way-to-get-the-description-of-a-package-rather-than-the-software-it-contains/46742/9 "2024-06-09T22:36:30Z")
That, and sometimes the thing being overridden is a whole package, and so a complete accounting would include detailed descriptions of every transitive dependency.
---
### Author:  [@doronbehar](https://discourse.nixos.org/u/doronbehar)
#### Post date: [June 10, 2024, 6:23am UTC](https://discourse.nixos.org/t/is-there-a-way-to-get-the-description-of-a-package-rather-than-the-software-it-contains/46742/10 "2024-06-10T06:23:22Z")
> [@abathur](#):
>
> - a number of platform-specific descriptions
> - descriptions that ~lie about some feature being enabled if you aren’t on the platform the description was evaluated on
Hmm right I didn’t thought about it… The website’s description are probably evaluated by an `x86_64-linux` system. Perhaps the module system could be aware of such non trivial default values?