Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

nixos/icingaweb2: Fix php extensions package #86945

Open
wants to merge 1 commit into
base: master
from

Conversation

@dasJ
Copy link
Member

dasJ commented May 5, 2020

Motivation for this change
Things done
  • Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
  • Built on platform(s)
    • NixOS
    • macOS
    • other Linux distributions
  • Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
  • Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
  • Tested execution of all binary files (usually in ./result/bin/)
  • Determined the impact on package closure size (by running nix path-info -S before and after)
  • Ensured that relevant documentation is up to date
  • Fits CONTRIBUTING.md.
@dasJ
Copy link
Member Author

dasJ commented May 5, 2020

@GrahamcOfBorg test icingaweb2

Copy link
Contributor

talyz left a comment

Note that we now have functions to build a PHP with extensions - php.withExtensions or php.buildEnv. They're documented in doc/languages-frameworks/php.section.md if you want to know more. It's not strictly necessary to use them, of course - with the current functionality in the module, it shouldn't really matter; it mostly matters if you want to implement a way for people to specify the PHP package in use.

If you want to go with the current solution, I would recommend using php.extensions instead of phpExtensions, though. phpExtensions should probably be removed anyways to lessen confusion.

@dasJ
Copy link
Member Author

dasJ commented May 9, 2020

@talyz Using php.extensions instead of phpExtensions is not really obvious. Wouldn't lib.warn help in that case?

@talyz
Copy link
Contributor

talyz commented May 9, 2020

It's not, no, which is why I think it should be removed. This isn't something that we've decided to do, though - just my personal opinion. I'll probably fix it in a future pr. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

2 participants
You can’t perform that action at this time.