PHP: Improve package installation experience

[sagikazarmark]

I find the current PHP package installation experience a bit weird, but maybe I'm doing something wrong.

When PHP language support is enabled, devenv automatically adds pkgs.php (or it's equivalent based on extensions, selected version, etc) to the list of packages in the profile.

languages.php = {
  enable = true;
};

By default, it also installs Composer using that same package, but its configurable:

languages.php = {
  enable = true;
  packages.composer = null; # or whatever
};

Normally, people want to use the same PHP package to install addition PHP packages and right now that's not trivial IMO.

For example, if I wanted to install psalm, a static analysis tool for PHP, I need to use a different PHP package right now:

languages.php = {
  enable = true;
  packages.composer = null; # or whatever
};

packages = with pkgs; [
  php.packages.psalm # This is a different PHP package
];

Am I missing something? Is there an easy way to install additional PHP packages with the same PHP environment?

As I mentioned above, there is packages.composer, but I don't think it's feasible to list all PHP packages in the module.

I was thinking about adding something similar to extensions:

languages.php = {
  enable = true;

  extraPackages = [ "psalm" ];
};

It makes packages and extraPackages somewhat redundant though.

Again: please let me know if I'm missing something and I'm happy to add an example clarifying how this really works.

I'm also happy to work on a PR adding the above suggested option.

Thanks!

[domenkozar]

cc @shyim who did most of the PHP work

[shyim]

sounds good, but I guess I would name the option just packages. We never had the struggle as we manage tools with composer as not all use nix and we have custom extensions 😅 .

I would make try then to move composer also there wdym?

[sagikazarmark]

sounds good, but I guess I would name the option just packages.

I think that makes sense, although it would be a breaking change.

We never had the struggle as we manage tools with composer as not all use nix and we have custom extensions 😅 .

I did that for a while too, but I've grown to like how Nix installs those tools.

I would make try then to move composer also there wdym?

Composer is just another package, so that could work.

I vaguely recall, however, that someone wanted to disable it and that's why it's possible to pass null as the composer package at the moment. So my recommendation is to not install composer by default at all, but allow users to pass it in as a package.

After the change, here is how it would look like:

languages.php = {
  enable = true;

  packages = [ "composer" "psalm" ];
};

If the breaking change is not a concern, I'm happy to work on this change.

[domenkozar]

We can keep backwards compatibility by handling it differently if it's a list of strings vs a list of derivations.