Skip to content

Conversation

wellWINeo
Copy link

@wellWINeo wellWINeo commented May 16, 2025

Related issues:

Changes:

  • add package option to services.shadowsocks and related changes
  • add tests with pkgs.shadowsocks-rust
  • add postfix 'libev' to original tests

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:
  • 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/)
  • 25.05 Release Notes (or backporting 24.11 and 25.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.

@github-actions github-actions bot added 6.topic: nixos Issues or PRs affecting NixOS modules, or package usability issues specific to NixOS 8.has: module (update) This PR changes an existing module in `nixos/` labels May 16, 2025
@NixOSInfra NixOSInfra added the 12.first-time contribution This PR is the author's first one; please be gentle! label May 16, 2025
@github-actions github-actions bot added 10.rebuild-darwin: 0 This PR does not cause any packages to rebuild on Darwin. 10.rebuild-linux: 1-10 This PR causes between 1 and 10 packages to rebuild on Linux. labels May 16, 2025
@wellWINeo
Copy link
Author

You've been reviewers for previous pr for shadowsocks module, so I thought it would be appropriate to ping you. If that's not the case, I apologize.

@pSub @hmenke

};
};

getServiceUnitName = pkg: "shadowsocks-${pkgTitleMap.${getName cfg.package}}";
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like all the transformations on getName reduce to just the identity?

Suggested change
getServiceUnitName = pkg: "shadowsocks-${pkgTitleMap.${getName cfg.package}}";
getServiceUnitName = getName cfg.package;

};

getServiceUnitName = pkg: "shadowsocks-${pkgTitleMap.${getName cfg.package}}";
getExecCommand = pkg: runMode: commandsMap.${getName cfg.package}.${runMode};
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think there is also getExecutable, no?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I found lib.getExe, but shadowsocks-libev and shadowsocks-rust provides multiple binaries (without mainProgram). Also i have plans to add the ability to use other binaries in the future (e.g. ss-local)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is lib.getExe' for this use case, which allows you to specify the binary name.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for the observation. But in any case a conversion table will be needed, because different packages have different binary names (libev -> ss-server, rust -> ssserver). Anyway module relies on knowledge of binaries name, so i doesn't see point in using lib.getExe'. If you think different, i would be happy for your feedback

@@ -48,14 +64,27 @@ in
'';
};

package = mkPackageOption pkgs "Shadowsocks" {
default = "shadowsocks-libev";
example = "services.shadowsocks.package = pkgs.shadowsocks-libev";
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think example should be only the right-hand side.

Suggested change
example = "services.shadowsocks.package = pkgs.shadowsocks-libev";
example = "pkgs.shadowsocks-libev";

That said, I don't think an example is really necessary here.

package = mkPackageOption pkgs "Shadowsocks" {
default = "shadowsocks-libev";
example = "services.shadowsocks.package = pkgs.shadowsocks-libev";
extraDescription = "Shadowsocks implementation package to use.";
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does mkPackageOption not accept description?

Suggested change
extraDescription = "Shadowsocks implementation package to use.";
description = "Shadowsocks implementation package to use.";

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is no description argument. As i found it's generated automatically, so extraDescription makes no sense. I'll remove it

@wellWINeo wellWINeo force-pushed the feature/shadowsocks-package-option branch from 74bc19d to 950abff Compare May 22, 2025 19:41
@wegank wegank added the 12.approvals: 1 This PR was reviewed and approved by one person. label May 23, 2025
@wellWINeo wellWINeo requested a review from r-vdp June 10, 2025 20:16
@@ -164,22 +182,29 @@ in
(noPasswd && !noPasswdFile) || (!noPasswd && noPasswdFile);
message = "Option `password` or `passwordFile` must be set and cannot be set simultaneously";
}
{
# Ensure localAddress is a string if package is shadowsocks-rust
assertion = !(cfg.package == pkgs.shadowsocks-rust && !lib.strings.isString cfg.localAddress);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should probably check pname here. People like to override the package with package option.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tanks for highlight this corner case

@wellWINeo wellWINeo force-pushed the feature/shadowsocks-package-option branch from 950abff to 9457218 Compare June 13, 2025 16:26
@wellWINeo wellWINeo requested a review from Aleksanaa June 13, 2025 16:28
@Aleksanaa
Copy link
Member

@ofborg test shadowsocks.basic-libev shadowsocks.basic-rust shadowsocks.v2ray-plugin-libev shadowsocks.v2ray-plugin-rust

@nixpkgs-ci nixpkgs-ci bot added the 2.status: merge conflict This PR has merge conflicts with the target branch label Jul 26, 2025
@wellWINeo wellWINeo force-pushed the feature/shadowsocks-package-option branch from 9457218 to 8bdd8cb Compare August 17, 2025 10:40
@nixpkgs-ci nixpkgs-ci bot removed the 2.status: merge conflict This PR has merge conflicts with the target branch label Aug 17, 2025
Closes: NixOS#384226

- add `package` option to services.shadowsocks and
related changes
- add tests for `pkgs.shadowsocks-rust`
- add postfix 'libev' to original tests
@wellWINeo wellWINeo force-pushed the feature/shadowsocks-package-option branch from 8bdd8cb to ea14385 Compare August 17, 2025 10:50
@wellWINeo
Copy link
Author

@Aleksanaa

Apologies for the ping - just following up as this has been open for three months. I've rebased onto master today to fix conflicts. ofborg tests were triggered but stuck in queue for ~two months.

I'm still eager to contribute this - happy to make any tweaks for merge. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
6.topic: nixos Issues or PRs affecting NixOS modules, or package usability issues specific to NixOS 8.has: module (update) This PR changes an existing module in `nixos/` 10.rebuild-darwin: 0 This PR does not cause any packages to rebuild on Darwin. 10.rebuild-linux: 1-10 This PR causes between 1 and 10 packages to rebuild on Linux. 12.approvals: 1 This PR was reviewed and approved by one person. 12.first-time contribution This PR is the author's first one; please be gentle!
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants