-
Notifications
You must be signed in to change notification settings - Fork 7.8k
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
Comments
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? |
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. |
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: |
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.
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.
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. |
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.
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. |
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.
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 |
On shared servers, it's a somewhat common practice to have commands Installer also should enable selection which extensions are enabled and create php.ini with correct
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. |
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)?
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. |
Thanks for the mention :) Winget does support PHP now, with package names such as 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 As far as feature-parity goes, |
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
The text was updated successfully, but these errors were encountered: