Phpspreadsheet: Install with composer

Created on 21 Sep 2016  路  21Comments  路  Source: PHPOffice/PhpSpreadsheet

Any support to install this package with composer?

Most helpful comment

1.0 makes the most sense imo. I was confused why you were in alpha at 1.8. :)

Sent from my iPhone

On 9 Dec 2016, at 04.29, Adrien Crivelli <[email protected]notifications@github.com> wrote:

Thanks, @Markhttps://github.com/Mark, I'll tag an alpha release as soon as we decide whether the next version should be a 2.0 (because following PHPExcel versioning), or a 1.0 (because PhpSpreadsheet is a "new" project).

I would personally go for a 1.0 to break away as much as possible from PHPExcel. What do you think ?

-
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com/PHPOffice/PhpSpreadsheet/issues/20#issuecomment-265924595, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AIBYsqxeXd2erI8IP-OCoVucl33emlVqks5rGMsYgaJpZM4KDSBw.

All 21 comments

Not until it's properly stable enough

You can use the composer repositories tag, documented here

@MarkBaker

Not until it's properly stable enough

Would you rather recommend sticking to PHPExcel then? I'm starting a new feature on a project which already has PHPExcel 1.7.9 in it, and would like to know if you (the author's) would recommend using PHPSpreadsheet or PHPExcel?

Forced to make a choice at this point, I'd recommend using a more up-to-date version of PHPExcel (1.8.1 is the last production release of PHPExcel); but to be aware that a change to using PHPSpreadsheet in the future won't be backward compatible with PHPExcel

Could I recommend that you put a note in the root README.md that this project is not yet stable and that people coming to this new should still use PhpExcel?

Then, when PhpSpreadsheet is stable, update the README.md again.

@caponica Agreed. The section https://github.com/PHPOffice/PhpSpreadsheet#phpexcel-vs-phpspreadsheet- in the README.md mainly addresses contributions but should probably mention that PhpSpreadsheet is still in development

addressed in 699d11f3a45a15ae4ebd3f4f637d0318b62cfa7c

Any reason why not using Composer still? I personally know no one using custom autoloader except for legacy reasons, and that's strongly discouraged as you can't benefit from the performance gains offered by composer and with the --authoritative-classmap option, files autoloaded another way than composer will simply fail.

If the release is not stable, you can still tag it as alpha, beta or rc. You have several PHP projects as examples.

I am not against submitting to packagist as an alpha (or even without any releases), but unfortunately I don't have access to PHPOffice namespace over there. So that's up to @Progi1984 or @MarkBaker ...

I let @MarkBaker choosing as lead dev of the project. But if he accepts, i can push the package on Packagist.

I think it would be a good thing. We are far from being stable, but it would allow us to explicitly mark the code as alpha (and beta later on).

I think if you target the modern PHP community, Composer is the thing to get users :) The PHP community is well educated regarding semver with Composer, so as long as you follow it and don't abuse of it it should go well even if the package is far from being stable.

As @shadiakiki1986 says above, if you're happy to accept the current instability and recommendations above, you can install with composer like this:

{
  "repositories": [
    {
      "type": "vcs",
      "url": "https://github.com/PHPOffice/PhpSpreadsheet"
    }
  ],
  "require": {
    "PHPOffice/PhpSpreadsheet": "dev-master"
  }
}

@adamhopkinson the issue is about making good use of Composer for managing this package, stable or not, instead of giving a workaround to install a GitHub package with Composer.

+1 for Composer. I'd use it if it was available, alpha or beta. That means I'd discover bugs and report them, which would help improve the software overall. Without Composer I will not use it for the reasons mentioned by @theofidry.

I think that pattern applies to a lot of users. I don't see how making it available on composer would do any harm.

I've added PHPSpreadsheet to Packagist, but I haven't modified the composer in any way to flag it as alpha yet

馃憤

Thanks, @Mark, I'll tag an alpha release as soon as we decide whether the next version should be a 2.0 (because following PHPExcel versioning), or a 1.0 (because PhpSpreadsheet is a "new" project).

I would personally go for a 1.0 to break away as much as possible from PHPExcel. What do you think ?

1.0 makes the most sense imo. I was confused why you were in alpha at 1.8. :)

Sent from my iPhone

On 9 Dec 2016, at 04.29, Adrien Crivelli <[email protected]notifications@github.com> wrote:

Thanks, @Markhttps://github.com/Mark, I'll tag an alpha release as soon as we decide whether the next version should be a 2.0 (because following PHPExcel versioning), or a 1.0 (because PhpSpreadsheet is a "new" project).

I would personally go for a 1.0 to break away as much as possible from PHPExcel. What do you think ?

-
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com/PHPOffice/PhpSpreadsheet/issues/20#issuecomment-265924595, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AIBYsqxeXd2erI8IP-OCoVucl33emlVqks5rGMsYgaJpZM4KDSBw.

Can someone help me with the error below?

$ composer require phpoffice/phpspreadsheet
Using version ^1.2 for phpoffice/phpspreadsheet
./composer.json has been created
Loading composer repositories with package information
Updating dependencies (including require-dev)
Your requirements could not be resolved to an installable set of packages.

Problem 1
- phpoffice/phpspreadsheet 1.2.1 requires ext-gd * -> the requested PHP extension gd is missing from your system.
- phpoffice/phpspreadsheet 1.2.0 requires ext-gd * -> the requested PHP extension gd is missing from your system.
- Installation request for phpoffice/phpspreadsheet ^1.2 -> satisfiable by phpoffice/phpspreadsheet[1.2.0, 1.2.1].

To enable extensions, verify that they are enabled in your .ini files:
- C:\Users\Ligeirinho\Downloads\php-7.2.4-nts-Win32-VC15-x64\php.ini
You can also run php --ini inside terminal to see which files are used by PHP in CLI mode.

Installation failed, deleting ./composer.json.

@ligeirinhorj according to the stack trace you are missing the extension gd. That said I advise you to try an actual support plaftorm, e.g. StackOverflow, rather than highjacking an unrelated issue for it

Was this page helpful?
0 / 5 - 0 ratings

Related issues

garnold picture garnold  路  5Comments

PowerKiKi picture PowerKiKi  路  4Comments

alexbog8 picture alexbog8  路  4Comments

Blacknife picture Blacknife  路  4Comments

sadlyblue picture sadlyblue  路  3Comments