Skip to content

sslh: 1.16 -> 1.17#7317

Merged
jagajaga merged 1 commit intoNixOS:masterfrom
k0ral:sslh
Apr 11, 2015
Merged

sslh: 1.16 -> 1.17#7317
jagajaga merged 1 commit intoNixOS:masterfrom
k0ral:sslh

Conversation

@k0ral
Copy link
Contributor

@k0ral k0ral commented Apr 11, 2015

Successfully built locally.

jagajaga added a commit that referenced this pull request Apr 11, 2015
@jagajaga jagajaga merged commit 7c47ebe into NixOS:master Apr 11, 2015
vkryachko added a commit to vkryachko/nixpkgs that referenced this pull request Sep 9, 2023
Having used `callPackage` a bit, it seems a bit odd and inconsistent that modules
require `...` in their signatures as opposed to figuring out the
signature and passing only what's requested, like `callPackage` does.

Now I don't know if there is an actual reason for why it is important
for modules to require `...`, but I could not find any and upon a brief
chat with @infinisil, it seemed like there might not be a reason. So if
you know of a reason, please let me know.

Worth noting that, as currently implemented, it's is a breaking change,
namely modules that use at-pattern arg capture don't work (`{ ...
}@args`, args used to contain all available module args, but is now
empty, see newly added failing test for details). I don't have any data
on how common it is to write modules with at-pattern capturing, so would
like to get some guidance on how important it is to preserve this
behavior.

It's possible to make it a non-breaking change by detecting `...` and/or `@args`
with something like NixOS#194992 or rather with a new builtin like
was proposed in NixOS#7317, and passing all available arguments if detected.

Would like to get your thoughts on the idea to see if there are any
strong objections to pursuing this further.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants