goutline: init at 1.0.1

[wwmoraes]

Description of changes

https://github.com/1pkg/goutline

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[mattpolzin]

Thanks for the contribution!

Please pull the change to maintainers-list.nix out into its own maintainers: add wwmoreas commit prior to your init commit for the goutline package.

Other than that, I think this is ready to get tested. I've verified the details of your maintainers-list addition.

[mattpolzin]

Upon closer look, I may have another couple of suggestions regarding the packaging, but before I mention those: Have you considered whether this package is used broadly enough to warrant maintaining it in Nixpkgs (per the informal criteria found here)? If not, there's always the NUR as mentioned in that same section of the documentation. My question comes from the last commit to the project occurring 4 years ago and the GitHub repository not seeing any stars -- neither of which means the project should not be a part of Nixpkgs, but both of which may indicate an unmaintained and/or niche project that not many users will seek out.

[wwmoraes]

Upon closer look, I may have another couple of suggestions regarding the packaging, but before I mention those: Have you considered whether this package is used broadly enough to warrant maintaining it in Nixpkgs (per the informal criteria found here)? If not, there's always the NUR as mentioned in that same section of the documentation. My question comes from the last commit to the project occurring 4 years ago and the GitHub repository not seeing any stars -- neither of which means the project should not be a part of Nixpkgs, but both of which may indicate an unmaintained and/or niche project that not many users will seek out.

That's a fair question. I presume the CLI isn't popular as it is installed from source by its companion Visual Studio Code extension if its not on the PATH. The extension documentation mentions that.

Commit-wise its expected: the Golang programming language didn't introduce any breaking changes to its tagging syntax, so this tool has no need to update often. Excuses apart, I have to agree that it looks niche. I'm fine with keeping it in a NUR, as I already have a repository I use as testbed to avoid development noise here.

[mattpolzin]

I'll make my one other suggested change (in the following comments) and then I suggest you leave the PR open and we see if (a) it gets some thumbs up indicating there's demand for it or (b) another nixpkgs committer merges it. I am a very new committer so I don't know if us committers exercise our own judgement in saying a package is "too niche" or not and for now I'll err on the side of leaving this door open.

Commit-wise its expected: [...] this tool has no need to update often.

Perhaps the upstream author would accept a PR that added Go module support since that really is something that would make a difference given the package needs an external dependency. That's just an off hand observation.