I have fixed some small stuff in the postInstall hook with pre-generating stubs of PHP functions that are write once and required to be located in the vendor directory of composer. So this is perfect to do on build time because it results in a package that just works :-)

@jtojnar The second big thing I've done to the generated files is to change a bit how the php-packages.nix file looks, because it did the build of the package in there which I found inconvenient. So I moved to define the derivation in default.nix instead.

Here's a diff of that file:

diff --git a/pkgs/development/php-packages/language-server/php-packages.nix b/pkgs/development/php-packages/language-server/php-packages.nix
index a6629d15fc6..1dee7256ef9 100644
--- a/pkgs/development/php-packages/language-server/php-packages.nix
+++ b/pkgs/development/php-packages/language-server/php-packages.nix
@@ -1,4 +1,4 @@
-{ composerEnv, fetchurl, fetchgit ? null, fetchhg ? null, fetchsvn ? null }:
+{composerEnv, fetchurl, fetchgit ? null, fetchhg ? null, fetchsvn ? null, noDev ? false}:
 
 let
   packages = {
@@ -174,6 +174,12 @@ let
     };
   };
   devPackages = {};
-in {
-  inherit packages devPackages;
-}
+in
+composerEnv.buildPackage {
+  inherit packages devPackages noDev;
+  name = "felixfbecker-language-server";
+  src = ./.;
+  executable = true;
+  symlinkDependencies = false;
+  meta = {};
+}
\ No newline at end of file

Keep in mind that I put a generated file over the one submitted here to generate this diff. So the pluses are the ones from composer2nix and the minuses are my changes.

And the change to not have the derivation defined in php-packages.nix led to changes in default.nix that defines the derivation there instead.

And that file I've also changed to not import nixpkgs as well. So here's a diff of the default.nix.

diff --git a/pkgs/development/php-packages/language-server/default.nix b/pkgs/development/php-packages/language-server/default.nix
index 4808807f186..d839f377a77 100644
--- a/pkgs/development/php-packages/language-server/default.nix
+++ b/pkgs/development/php-packages/language-server/default.nix
@@ -1,46 +1,13 @@
-{ pkgs, buildComposerEnv, php, noDev ? true }:
+{pkgs ? import <nixpkgs> {
+    inherit system;
+  }, system ? builtins.currentSystem, noDev ? false}:
 
 let
-  langServerPkg = import ./php-packages.nix {
-    composerEnv = buildComposerEnv;
-    inherit (pkgs) fetchurl fetchgit fetchhg fetchsvn;
+  composerEnv = import ./composer-env.nix {
+    inherit (pkgs) stdenv writeTextFile fetchurl php unzip;
   };
-in buildComposerEnv.buildPackage rec {
-  inherit noDev;
-  inherit (langServerPkg) packages devPackages;
-
-  pname = "php-language-server";
-  version = "5.4.6";
-
-  src = ./.;
-
-  executable = true;
-  symlinkDependencies = false;
-
-  nativeBuildInputs = [ pkgs.makeWrapper ];
-
-  # We remove the symlink created for the bin path because the php file provided
-  # miss a shebang. So we'll just wrap it instead.
-  postInstall = ''
-    rm $out/bin
-    mkdir -p $out/bin
-    makeWrapper ${php}/bin/php $out/bin/${pname} \
-      --add-flags "$out/share/php/${pname}-${version}/vendor/bin/${pname}.php"
-
-    # Change permissions so we can write the stubs
-    chmod u+w $out/share/php/${pname}-${version}/vendor/felixfbecker/language-server/
-
-    # Generate the stubs file
-    composer run-script --working-dir=$out/share/php/${pname}-${version}/vendor/felixfbecker/language-server parse-stubs
-
-    # Remove the permissions we added
-    chmod u-w -R $out/share/php/${pname}-${version}/vendor/felixfbecker/language-server/
-  '';
-
-  meta = with pkgs.lib; {
-    description = "PHP Implementation of the VS Code Language Server Protocol";
-    license = licenses.isc;
-    homepage = https://github.com/felixfbecker/php-language-server;
-    maintainers = with maintainers; [ etu ];
-  };
-}
+in
+import ./php-packages.nix {
+  inherit composerEnv noDev;
+  inherit (pkgs) fetchurl fetchgit fetchhg fetchsvn;
+}
\ No newline at end of file

This derivation is fairly closed to the one generated in php-packages.nix, except from that I nedeed to add a postInstall for this package because of reasons.

Keep in mind that I put a generated file over the one submitted here to generate this diff. So the pluses are the ones from composer2nix and the minuses are my changes.

@etu As someone interested in composer2nix I'd love to see this completed. Are you just looking for some feedback from @svanderburg?

As someone interested in composer2nix I'd love to see this completed.

Yes, me as well. I see the possibility to change how we package some PHP deps. For example we could change the things that download phar files to build it from source easily.

This would also give the opportunity to package more things that doesn't distribute phar files and requires composer to build.

Are you just looking for some feedback from @svanderburg?

Yes.

@svanderburg Would you be able to provide some feedback on the approach here? Your input could help @etu provide a fair bit of value to the php ecosystem in nixpkgs.

@aanderse To try to move this forward I've emailed @svanderburg :)

I've just rebased this on master and fixed the conflict.

@aanderse I haven't got any response to my email yet, so not sure how to proceed :/

composer2nix has seen no activity in a year and after multiple attempts to contact @svanderburg there has been no acknowledgement. At this point we should assume that @svanderburg has no interest or time and continue to assume so until either they or someone working with them confirms otherwise.

Given @svanderburg has no interest we must rely internally to move this forward.

@jtojnar @globin @offlinehacker we look to you for review and possible advice on how to proceed with this PR. If you're unable to provide either can you please let us know (and further to that suggest someone else who can, if possible?)

Hi,

Sorry about my absence and that it took so long to respond. It's not that I'm not interested in composer2nix, but I'm basically in the situation that I'm buried alive in huge piles of issues with all my projects (e.g. those of my daytime job, node2nix, Android stuff, disnix) and I'm (sort of) trying to manage my time in such a way that I can help resolving them.

The changes in the PR look mostly fine to me and I think there is little we need to change.

The only thing that is not entirely clear to me is how we can conveniently update the composer2nix infrastructure, whenever composer2nix changes? The build infrastructure is basically part of the composer2nix tool, and whenever that gets changed, we want to update the infrastructure in Nixpkgs as well. I don't think we want to maintain a fork of this functionality in Nixpkgs.

For node2nix (that I also maintain) I basically created a shell script that we run each time that we want to bump package versions or when node2nix itself needs to be upgraded: https://github.com/nixos/nixpkgs/blob/master/pkgs/development/node-packages/generate.sh

When we run the script the packages get regenered and the corresponding node-env.nix file (that contains the build infrastructure) gets updated as well. This allow us, for example, to instantly bump all NPM deployments when a new release of node2nix comes out.

I think to be able to manage PHP packages, it would be nice to have a similar mechanism. In the PR, I could not see that such a facility exists, so that when composer2nix gets updated we can get the Nixpkgs stuff updated as well in one go.

Maybe this is something that we have already though about, but I could not find it anywhere in the PR

@svanderburg Thanks for your reply and comments! Much appreciated.

@svanderburg Thank you for your response, this gives me some ideas in both upstreaming some of the changes and some additional changes to make it easier to integrate the expressions generated. Maybe we don't get this in for 19.09, maybe it's more 20.03. I'll have my vacation coming up soon. Maybe I have the time to hack a bit more then, but It's very unclear at the moment 😄

I've haven't had the time to work on this and I will put it off for a bit more... So I'm closing it for now but keeping my branch.