Improve organization of PHP ecosystem

[3noch]

I have a few gripes with the current PHP system and I'd like to fix them but want to hear some feedback first:

1. Unlike the Haskell ecosystem, so far as I know, you cannot start with a PHP version and get to a set of packages. E.g. for Haskell you can do haskell.ghc802.<package> to select packages that support a specific compiler. But in PHP you cannot do php71.<package>. Instead you must use php71Packages. This is annoying because you end up writing functions like { php, phpPackages, ... }: when they could just be written { php }:. This could be solved either by adding a packages attribute to php70 and php71. Or it could be solved by adding a php attribute to the package sets which points to the actual interpreter.
2. There is no easy way to configure a php on your path that has a custom php.ini and loads certain extensions. I'm currently using a rather primitive script to do it: https://gist.github.com/3noch/79255f8c5ec3c287b91b7484265a89a8. However, it would be very convenient for the package sets to have a phpWithConfig attribute resembling my example.

I'd be willing to get the ball rolling on both of these but I'm new to PHP and PHP's Nix integration so I'm all ears!

[3noch]

cc @globin @fpletz

[mogria]

I'd be rather fond of such a change 👍

I've solved the second issue with makeWrapper and passing a custom php config via the -c flag instead of using the environment variable:
https://github.com/mogria/rhymebin/blob/master/default.nix

[globin]

I'd definitely support work on this :)

[3noch]

Great. I'll start some PRs. But I'm curious about some preferences:

1. Do you want php.packages? or phpPackages.php? To mirror Haskell's system, I sort of prefer php.packages but even that isn't exactly the same.
2. Do you want to use makeWrapper or my weird thing? I don't know how to use makeWrapper but I can learn. I just want to preserve the ability for the end user to keep cascading more INI files, which is why I used the env var.

[MarcWeber]

https://github.com/MarcWeber/nixpkgs/tree/export/experimental/php already has php.apcu for instance. It also offers more sophisticated php fpm implementation knowing how many services to start.

[CMCDragonkai]

Is there some sort of easy way to install new extensions for the current method of integrating nix with php? It appears that there's some sort of flag configuration on the interpreter default.nix. Perhaps overriding it and adding paths to the new extensions can work?

Installing extensions and installing packages are slightly different. I think installing extensions may need to work like how we need to build a new python environment with packages by overriding the extraLibs property, while php packages are generally loaded project specific similar to npm. But unlike node, there's no global package loader part of the language specification, instead the community settled around "autoloader" variants, one of which is the composer autoloader, but there are other ones available too.

[svanderburg]

A couple of days ago, I implemented a very minimal prototype/proof of concept implementation of composer2nix ( https://github.com/svanderburg/composer2nix). It can already be used for some small/limited use cases. However, it is far from complete/functional yet. I thought I was the first one to start this effort, but a thorough search revealed that somebody else did an attempt before me. Like my attempt, this implementation is in the very early stages: https://github.com/mogria/composer2nix . Furthermore, the project seems to be inactive for a while. I just contacted the author of the older implementation to see what his plans are. I only need it for a couple of side projects, but working on another generator looks like a nice technical challenge.

…

On Tue, Jul 11, 2017 at 2:15 PM, Roger Qiu ***@***.***> wrote: Is there some sort of easy way to install new extensions for the current method of integrating nix with php? It appears that there's some sort of flag configuration on the interpreter default.nix. Perhaps overriding it and adding paths to the new extensions can work? Installing extensions and installing packages are slightly different. I think installing extensions may need to work like how we need to build a new python environment with packages by overriding the extraLibs property, while php packages are generally loaded project specific similar to npm. But unlike node, there's no global package loader part of the language specification, instead the community settled around "autoloader" variants, one of which is the composer autoloader, but there are other ones available too. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#24432 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABGY90pmbM-zkN6fO8xwQICUlTJCUraxks5sM4OCgaJpZM4Msefc> .

[CMCDragonkai]

@svanderburg Will your tool support deriving the extension dependencies specified inside the composer.json?

I noticed that installing a PHP extension along with PHP inside a nix-shell, the php doesn't pick up the extension automatically. This is unlike the python infrastructure, where a python package will be picked up automatically by the python interpreter inside a nix-shell instance (but not within a nix-env instance). Is it not possible to use shared libraries as extensions for PHP?

Looking over all the implementations right now, I think it might be a good idea to differentiate "packages" from "extensions". Newbies might get confused when they see "packages", when they really are extensions. PHP/composer "packages" can't actually get bundled into the php interpreter, the developer must supply some form of autoloader.

Therefore I think for building a PHP environment, one should supply an overridden list of extensions which builds the relevant php environment.

There are also php "apps" that are currently under the phpPackages namespace, such as phpcs and my PRed phpcbf. Do these make sense to be under phpPackages, since they are command line executables, and expose nothing to the php interpreter.

[CMCDragonkai]

Note here is another way to build a php environment with the needed extensions: http://stesie.github.io/2016/08/nixos-php-and-phpstorm

These patterns should be able to be adapted into a build env function/override. Kind of like:

php.buildEnv.override {
  extensions = with phpPackages; [
    redis
    xdebug
  ]
}

To avoid needing to recompile everything each time, should this all be done with shared object? I'm not entirely sure between what extensions can/must be statically compiled and what can/must be dynamically linked.

[svanderburg]

I think so, but there are still many aspects I need to investigate. This will take some time.

…

On Wed, Jul 12, 2017 at 5:23 AM, Roger Qiu ***@***.***> wrote: @svanderburg <https://github.com/svanderburg> Will your tool support deriving the extension dependencies specified inside the composer.json? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#24432 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABGY93AcEyXKqkvj1odkJjTWhU1WMUyJks5sNDw4gaJpZM4Msefc> .

[CMCDragonkai]

Was reading this https://static.domenkozar.com/nixpkgs-manual-sphinx-exp/stdenv.xml.html

And it mentioned that:

A list of dependencies used by stdenv to set up the environment for the build. For each dependency dir, the directory /bin, if it exists, is added to the PATH environment variable. Other environment variables are also set up via a pluggable mechanism. For instance, if buildInputs contains Perl, then the lib/site_perl subdirectory of each input is added to the PERL5LIB environment variable. See ? for details.

Perhaps a similar technique can be used for PHP extensions when they are just supplied as part of buildInputs.

[jbboehr]

I'm somewhat familiar with php-src, perhaps I can help. I'm very new to nix, so I apologize if I make a suggestion that is incompatible with the way things are meant to work.

Coming from ubuntu, my expectation would be that Scan this dir for additional .ini files in php -i would be set to ~/.nix-profile/etc/php/7.0/conf.d and that extensions installed would write an ini file to this directory. I'm not sure this is possible without making a patch to PHP, since it requires resolving the home directory.

To avoid needing to recompile everything each time, should this all be done with shared object? I'm not entirely sure between what extensions can/must be statically compiled and what can/must be dynamically linked.

Extensions not compiled statically into PHP are built as dynamic shared objects and opened via dlopen. Most extensions can work either way, however there may be some exceptions. Particularly, certain extensions are meant to (also) be consumed by other extensions and expose headers that require that they be compiled statically into php (spl and pdo for example).

[Gerschtli]

Hey, what is the state? I'm interested and would like to help!

[CMCDragonkai]

It should also be clarified why PHP extensions are called PHP packages, but most PHP packages (from the PHP community) are not available in Nixpkgs. I think eventually language-specific package sets should be abstracted out of nixpkgs and be brought in as overlays or something else.

[etu]

Something I don't like about the current PHP packaging is that it's as far as I've been able to try not possible to override the version of a package. I don't think that that's very nice...

[stale]

Thank you for your contributions.

This has been automatically marked as stale because it has had no activity for 180 days.

If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity.

Here are suggestions that might help resolve this more quickly:

1. Search for maintainers and people that previously touched the related code and @ mention them in a comment.
2. Ask on the NixOS Discourse.
3. Ask on the #nixos channel on irc.freenode.net.

[etu]

Thanks stale-bot, I think this is pretty much done in unstable.

We even have docs now: https://github.com/NixOS/nixpkgs/blob/master/doc/languages-frameworks/php.section.md

[etu]

We have some further work that we want to do though, such as making it easier to package composer packages etc.

But I think we have done a lot of the ground work around how we manage extensions and configuration of the interpreter itself.

We also separated interactive tools from extensions.