@GrahamcOfBorg build php72 php73 php74 php72Packages.exts php73Packages.exts php74Packages.exts nixosTests.nextcloud nixosTests.php

@GrahamcOfBorg build php72 php73 php74 php72Packages.exts php73Packages.exts php74Packages.exts nixosTests.nextcloud nixosTests.php

My only remaining comment is that I wonder if it becomes confusing (or overly verbose) to have php.packages.exts, especially for people newer to nixpkgs. Currently in my mind I wonder if php.packages and php.extensions (or php.pkgs and php.exts) is less confusing, but of course that would potentially end up making buildEnv more verbose. To alleviate that maybe we could have buildEnv operate on php instead of pp, like php.buildEnv { exts = with p; [ pkgs.imagick exts.opcache ]; }... but maybe I'm just rambling at this point and this doesn't make any sense... feel free to disregard 😄

@aanderse Yes, that's also something we discussed, but decided that the scope of the PR was big enough as is. Definitely something to think about, though :)

Currently in my mind I wonder if php.packages and php.extensions (or php.pkgs and php.exts) is less confusing, but of course that would potentially end up making buildEnv more verbose.

I think we should typically go for the verbose options. Readability is important. Now, we already use pkgs everywhere, so maybe not change that one, but exts is...strange.

I've added an enabledExtensions attribute and documentation about its use, fixed a typo in the nextcloud module which broke evaluation and fixed a few other minor things. The nextcloud and php tests pass.

I've added an enabledExtensions attribute and documentation about its use, fixed a typo in the nextcloud module which broke evaluation and fixed a few other minor things. The nextcloud and php tests pass.

ping @FRidh @jtojnar @etu @Ma27 @flokli does enabledExtensions sound good to you?

hi, i have a custom extension, that i need for my script. The extension build seems to work, but it's not available in php.packages. Im relatively new to nix, so pardon me.

my nix shell:

let
	pkgs = import <nixpkgs> {};
	phpGeos = pkgs.stdenv.mkDerivation rec {
		pname = "php-geos";
		version = "1.0.0";
		meta = {
			description = "php binding for GEOS";
		};

		src = pkgs.fetchurl {
			url = "https://git.osgeo.org/gitea/geos/php-geos/archive/${version}.tar.gz";
			sha256 = "0d90z591s092ys0d9gww2xw8vsvcdl6jbc90cgc6avq27dx4xk89";
		};

		nativeBuildInputs = [ pkgs.autoconf pkgs.automake pkgs.php74base ];
		preConfigure = "phpize";

		buildInputs = [ pkgs.geos ];

		installPhase = ''
			mkdir -p $out/lib/php/extensions
			cp modules/geos.so $out/lib/php/extensions/geos.so
		'';
	};
	php = pkgs.php74.buildEnv {
		extensions = exts: pkgs.php74.enabledExtensions ++ [phpGeos];
	};
in
	pkgs.stdenv.mkDerivation {
		name = "...";
		buildInputs = [
			php
			php.packages.composer
		];
	}

i have assumed that all enabled extensions would be passed to packages. When i run php -i my ext shows up. But when running /nix/store/pdllmyi9bdk7hc0bxgr8x01z27wgrdi9-php-with-extensions-7.4.4/bin/php -i (the php bin that composer is run with) the ext is not listed.

My previous version had an let phpPkgs = pkgs.phpPackages.override {php=php}, this seems to not work anymore since this change (?).

Hi @chpio!

You're about right all the way there!

Composer get's it's own environments PHP, and currently on master it doesn't use the overriden php. But this should be totally doable when we get #85026 together.

With that PR you should be able to use customPhp.packages.composer for instance.

This isn't something that have been easily doable before in Nix to do across all packages in a convenient way, so this will be a very exciting development :-)

If you can it would be great if you can check out that PR and report back there if it works for you.

@talyz and me will probably team up and try to get that one shaped up some day as well so we can get it in.

If you want a faster workaround in the meanwhile you could make your own derivation for composer that just use your custom php since composer is only a phar anyways.

Something like this can probably work for your case:

let
  myphp = pkgs.php74; # customize here
  mycomposer = writeScriptBin "composer" ''
    #!/bin/sh
    ${myphp} ${myphp.packages.composer}/libexec/composer/composer.phar \"$@\"
  '';
in {}

The only thing I know is missing from that composer is to inject unzip into the $PATH in that script.

Hi @chpio! Can you try #85026 now? Your use case should work fine now :)