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

Please make a php installation client for windows such as .msi #8727

Open
luohonen opened this issue Jun 8, 2022 · 9 comments
Open

Please make a php installation client for windows such as .msi #8727

luohonen opened this issue Jun 8, 2022 · 9 comments

Comments

@luohonen
Copy link

luohonen commented Jun 8, 2022

Description

Make a php.msi installer, for example, after installation, you can automatically configure environment variables and bring your own composer without additional configuration, which will greatly increase the novice's interest in learning, otherwise there will be fewer and fewer people willing to learn php. For the better development of php, please please please.

PHP Version

PHP8.1

Operating System

No response

@cmb69
Copy link
Member

cmb69 commented Jun 8, 2022

Prior to PHP 5.4.0, we shipped an MSI package, but that was dropped. I don't know the exact reasons, but part of these certainly was the additional work for the rather small benefit; I mean, an installer for CLI wouldn't be a big deal, but if you want to integrate with some Webserver (which may be IIS, NGINX or Apache or maybe something else altogether), that appears to be much harder. And after all, there are popular packages like XAMPP and WAMP which already bring a full fledged PHP dev environment, so why duplicate the effort?

Maybe the reason to drop the installer was that Microsoft offered PHP via their Web Platform Installer; but even if the no longer offer that, or don't provide current PHP versions (I'm not sure about that), there are still the other packages mentioned above.

Oh, and of course there is the issue regarding PECL packages. Should these also be installable via the MSI? That would cause quite some additional work, and there is already https://github.com/FriendsOfPHP/pickle which supports installing binary PECL packages (as well as building from source, and multiple version setups). So again, why duplicate the effort?

@luohonen
Copy link
Author

luohonen commented Jun 8, 2022

XAMPP and WAMP are just one way, because novice learning is just learning a language at the beginning, and should not directly bind apche or nginx or mysql, which increases the complexity of novice, they do not understand their relationship at first, maybe they I just want to simply use php, the zip method can be retained, but the msi installation package should also be used, because php also has a cli mode, nginx or mysql is not necessary, this php is not directly related, maybe they just use it and learning php, because I see that other programming languages have msi installation packages, in fact they can also be used in an integrated environment, it's not a conflict.

@KapitanOczywisty
Copy link

KapitanOczywisty commented Jun 8, 2022

I don't think that learning php on windows is a good idea, and most likely you'll end up on linux server anyway. I'd suggest to enable wsl and install ubuntu subsystem, with that installing php requires one command: sudo apt install php.

https://docs.microsoft.com/en-us/windows/wsl/

@cmb69
Copy link
Member

cmb69 commented Jun 8, 2022

I don't think that learning php on windows is a good idea, […]

If that is actually the case, we should fade out supporting Windows in the first place. Besides that this would save an aweful lot of work, we would push people in the right direction right away. I don't think, though, that learning PHP on Windows is a bad idea.

[…] and most likely you'll end up on linux server anyway.

Yeah – if you end up on a server at all. PHP is supposed to be a general-purpose scripting language, and if I understand @luohonen correctly, this request is more about the CLI SAPI than about any server SAPI.

I'd suggest to enable wsl and install ubuntu subsystem, […]

While that is certainly a good option, it requires some additional learning for those used to Windows, but not to Linux.

That said, I'm still not convinced that the benefits of shipping Windows installers would be worth the trouble of creating and maintaining them.

@KapitanOczywisty
Copy link

If that is actually the case, we should fade out supporting Windows in the first place.

There are legitimate reasons to use PHP on Windows, I just don't think that learning on windows is a good idea. PHP on win have some quirks, and for "novice" will be more painful to configure, even if adding complexity of WSL.

Yeah – if you end up on a server at all.

PHP is useful for building websites, I suspect most people, even while learning only on CLI (which i doubt) will end up making some sort of webpage - which probably will be on some Linux server. If somebody wants to learn PHP to build CLI apps, he probably chose a wrong language. You can say that supposed to be for everything, but in reality its tailored for web backend.

You can look at PHP tutorials, they are all starting with setting up xampp or other kind of web server (e.g. build-in one) or how to upload files to shared hosting.

@cmb69
Copy link
Member

cmb69 commented Feb 13, 2025

I had a closer look at this, and it turns out to be way more complex than I had expected. Even ignoring the different PHP variants we support on Windows: ZTS/NTS, x64/x86), still leaves the PHP version issue. Allowing only a single PHP version per machine, we could actually provide some helpful features (adding the PHP folder to PATH, for instance), but even when upgrading to a new minor or major PHP version, there would be issues regarding manually added PECL packages (which would need to upgraded manually). PIE may help with this, though (not sure about the current state of upgrade support).

However, only allowing a single PHP version would be somewhat limited. Multiple versions would, of course, be possible, but are harder to handle (for the MSI, but also for users). Python mitigates this somewhat with the Python launcher, but there is no such thing for PHP.

Regarding Composer: this has an installer for Windows which is based on InnoSetup, and as such doesn't use the MSI technology. As such a simple integration via a merge module is not possible (besides it it not clear whether a PHP installer should ship Composer, or whether a Composer installer should also offer to install PHP, let alone if such integration would even be desired by the Composer developers).

Anyhow, the good is that I've set up https://github.com/cmb69/php-msi, so there is something concrete to play with. Feel free to submit issues and pull requests there. Let's see where that goes.


You can look at PHP tutorials, they are all starting with setting up xampp or other kind of web server (e.g. build-in one) or how to upload files to shared hosting.

Indeed. However, XAMPP seems to be dormant (latest release ships with PHP 8.2.12, which has been released more than a year ago), and we already had php-src tickets where people tried to upgrade PHP in an older XAMPP release, struggling with this. There are alternatives which are up-to-date, but unless you're using such a package, setting up an working PHP environment on Windows is quite complicated for newbies, and some stuff is even hard to do for experienced users. Ever wondered why ext/openssl didn't work – oh, need to set up openssl.cnf in common files, or set the OPENSSL_CONF environment variable. Why would ext/curl fail to connect to HTTPS – ah, need get a cacert.pem, and configure that. Let alone setting up a working PHP FCGI with IIS – wtf.

@KapitanOczywisty
Copy link

However, only allowing a single PHP version would be somewhat limited. Multiple versions would, of course, be possible, but are harder to handle (for the MSI, but also for users).

On shared servers, it's a somewhat common practice to have commands php82, php81 for specific versions beside the newest as php and files with extensions like .php82 are handled by specific fpm version.

Installer also should enable selection which extensions are enabled and create php.ini with correct extension_dir, since everything there is compiled as shared library and nothing loaded by default.

However, XAMPP seems to be dormant

Docker probably killed that project.

Also take a look at winget: https://php.watch/articles/winget-install-php I think properly configured winget package manifest could be way better than creating msi.

@cmb69
Copy link
Member

cmb69 commented Feb 17, 2025

Installer also should enable selection which extensions are enabled and create php.ini with correct extension_dir, since everything there is compiled as shared library and nothing loaded by default.

Prior to working on the Git repo, I did a spike and had that implemented. But I was super unsure about it. For advanced users, that seems more complex than adding the extension to their php.ini manually, but for newbies it would be confusing; of course, there would be a "typical installation" option, but would that actually install (I mean which extension are typical)?

Also take a look at winget: https://php.watch/articles/winget-install-php I think properly configured winget package manifest could be way better than creating msi.

Ah, winget, right. I've totally forgot about that; thanks! Apparently, @Ayesh does a great job there! :) I have no idea what winget supports regarding a fine grained installation via ZIP archives. It seems that instead of a ZIP installation, an MSI installation might be an option, too. I'll try to have a closer look.

@Ayesh
Copy link
Member

Ayesh commented Feb 17, 2025

Thanks for the mention :)

Winget does support PHP now, with package names such as PHP.PHP.8.3, and Winget picks the x64 or x86 flavor and validates the zip files. It is, however, a pretty basic installation. It also lists msvc as a dependency. Here is the GitHub Actions workflow that automates this.

Winget did not support installing zip packages until recently, and even now, there is no support for custom binary aliasing yet. Although multiple PHP versions can co-exist simultaneously, there is no command aliases like php84. The manifest has it; it's just that Winget doesn't support them.

As far as feature-parity goes, choco, scoop, and now winget all support similar feature sets, but none of them are as sophisticated as a dedicate installer could be.

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

No branches or pull requests

4 participants