Phpspreadsheet: [documentation] Alternate install method

[Typel]

This is a feature request.

First, thanks for offering such a great library. I've been enjoying the benefits of PHPExcel for many years. I noticed that you've now deprecated that library and asked users to begin upgrading to PhpSpreadsheet. I just wanted to offer a small suggestion to help make that transition easier for some of the people tasked with upgrading this library across many different types of projects. I know it's popular to decry composer-resistent developers, but some of us are focused on creating fast, slim applications - often at the expense of developer comfort. To these developers, composer can add bloat and complexity.

What is the expected behavior?

Not everybody switching from the deprecated PHPExcel library wants to install composer and several dependencies into their project. An alternate method should be offered for people focused on keeping their projects slim. Minimally, the names of dependent libraries might be outlined so that they may be installed manually if actually needed for a given implementation.

What is the current behavior?

Only one installation method is offered - composer. This does not work for everyone's situation and ultimately alienates many of the people being asked to upgrade. I would consider adding a non-composer option similar to what the PHPMailer developers did when they jumped on the composer bandwagon a while back.

What are the steps to reproduce?

Open documentation, read documentation, leave disappointed.

Which versions of PhpSpreadsheet and PHP are affected?

PhpSpreadsheet-1.2.1
PHP-*

[PowerKiKi]

Duplicate of #387.

This won't happen. Composer is and will be mandatory. PHPMailer might be able to get by because they don't have any dependencies on libraries, but we do.

Not using composer today means PhpSpreadsheet _will_ crash. Trying to avoid those crashes would mean a lot more work for us to explain things and a lot more work for you to install and manage dependencies.

[Keorl]

You keep using the argument that it "will crash" if you give us a simple package like we had with PHPExcel instead of forcing everyone to either keep phpexcel or shoehorn composer into their projects.
I strongly disagree. It would only crash if people upgrade phpexcel by replacing the simple package, without looking at what changed and seeing that they need another library. But that never happens in reality (unless, maybe, you use composer to automatically upgrade everything for you ... but then I'm afraid that the composer process is the one that 'will crash' because your code may become incompatible with new versions of libraries - let alone introducing bugs from said new versions of libraries into a production app that was tested and validated with a specific version of the library). In reality, you have an app that is tested and validated before it goes into production, and that is done including a given version of libraries. If you decide to upgrade a library (be it a new version of phpspreadhseets or anything else), you actually have to work : look at changelog, choose latest suitable version, put it in your application, update your code if necessary, test&validate again. I don't see how composer can prevent any "crash" in this regard. The only gain would be to spend a few seconds telling composer to download the new version, instead of a few minutes doing it by yourself, and maybe a bit more time if you happen to need a new library ... once every 6 months (at best) or more probably 2 years. I can tell you 100% that my client will have no budget to upgrade libraries in the small project for no other reason than up-to-date sake. Right now I have an old project that I'm upgrading from php5.3 (see, that's how often I can upgrade stuff) to 7.3 and that's why I can finally also upgrade libraries in the process (including phpexcel ... which unfortunately is discontinued and replaced with this composer thing). I can tell you 100% that I won't have (or be able to!) upgrade phpspreadsheets before 2022 after that, given how small the project and how low the developments on it are. The hassle of learning a tool (composer) that I'll never use again (I have no other php project), shoehorning it in my project, utterly inflating the whole thing : I tried to download phpspreadsheets composer package from php-downloads, it's bigger than my whole project including all libraries, and includes a load of nonsense that shouldn't in any way be included in the app i'll deliver for production (docs, samples, changelogs ...).

tl;dr : no it "will not crash" if you provide a simple php zip for people who want to keep it simple. This idea only stems from the idea that people would then blindly update your library without a clue what they're doing, which won't happen in real scenarios. If you make a new version of phpspreadsheet, use a new 3rd party library, and I decide to upgrade ... I'll see it in the changelog and know that I have to add that library on top of updating my code to cater for the changes in phpspreadsheets.

[MAKS-dev]

I'm happy to see a fellow developer thinking the same way as I am.
My last update was to v1.8.2 (cannot go higher as the server is 7.0) and I never needed composer at all. Maybe some exotic functions do not work with this setup, but I did not encounter any crashes yet.
But they will never comply to this. Just until an alternative to composer comes along and everybody needs to switch over ;-)

[Keorl]

:)
"Alternative to composer ..." . Well, for now and from what I saw while trying to upgrade libraries in my project, this tool seems quite popular, one can hope it won't simply disappear or become obsolete. That said, it's a general issue with the growing tooling culture in software development : if your projects rely too much on tools, one day it may become a pain for you or more probably a nightmare for other people who'll have to start from your sources and see that nothing works.

Imho tools can be great, especially if you're focused on one technology (PHP in this case) so you use it all the time and it actually helps you a lot. But not if you switch techs all the time and those tools are just one more thing to learn or re-learn every time. And certainly not if the tools are more than a help for developers but actually take root in your projects in a way that the project simply can't be worked on without those tools and may become a nightmare for someone else in 5-10 years.

That said, until now with PhpSpreadsheer+Composer, I had NEVER run into libraries of any kind that actually REQUIRE the devs to work with a specific unrelated tool (in this case, a dependency manager is unrelated to working with spreadsheets) if they want to integrate the library into their project, without other solutions. It's the first time I see something like that ... and unfortunately it happens with a tool that's not just a simple thing without impact on your project : not only adding composer into an existing project isn't trivial, but also it's not just a developer QoL tool as you'd have to integrate it along your project all the way into production (which btw often doesn't have internet access, or even allows installing 3rd party software) (that's if you want to use it properly, I know you can use it in dev env and then push whatever it generated into production).

Anyway, I managed to make PhpSpreadsheet into a real php library. I downloaded the package from php-download (it emulates composer), made a PhpOffice directory inside my lib directory, and then extracted the content of "src" folders of the package for phpspreadsheet and the 3 dependancies. Here is what I have now

• PhpOffice/PhpSpreadsheet : pure content of the src (phpspreadsheet.php and so on), no composer pollution
• PhpOffice/PsrSimpleCache : content of its src = just 3 php files
• PhpOffice/Markbaker/Complex : content of its src
• PhpOffice/Markbaker/Matrix : content of its src
• in PhpOffice/Markbaker : I put the 4 files Autoloader.php and Bootstrap.php for both libraries, modified (renamed files, changed "src" to respective directories ...)
• in PhpOffice : created my own "autoload.php" : it require_once all 3 psr files, both markbaker boostraps, and spl_autoload_register for the whole of PhpSpreadsheet (full code has been posted by someone else in another thread, it's just a few lines)

And you know what ? Contrarily to what PowerKiki said countless times, I'm pretty sure it won't break. For starters, I'll probably not have to upgrade this library at all or for a long time. If I do, no matter if I used composer or not, it'd be with an impact study + acceptance tests and so on ... so it can't be 1 press of 1 button (if people use composer to keep up to date libraries without impact study and new tests, they're making wrong usage of the tool imho). IF I actually upgrade, it'll be extremely simple : download last version of PhpSpreadsheet here, find the src folder, and replace the contents in my project => Done. And lastly if PhpSpreadsheet new version asks for new library, I'll just copy it and add it to my phpoffice/autoload.php either like I did for psr or like I did for markbakers : total time to upgrade the library itself (not counting impact/changing my code if needed/acceptance) = a few minutes at most. A few minutes at most, once every forever, instead of many hours of learning composer and properly integrating it into my project. It'd be definitely worth it if phpSpreadhseet provides a simple php package like they did for phpExcel.

[chandrantwins]

Hi Keorl
Please can you upload your example project here.it will be helpful to avoid setup again in dev environment. Thanks for your support