Split repository in order to improve distribution of the library via composer

[rogeriopradoj]

@MarkBaker, @maartenba @Progi1984 @PHPOffice , sadly by now is quite impossible to use the PHPExcel via composer, using the current system...

I am trying for a long time since you have merged the composer.json, but the error The process timed out. appears all the time on running of composer install command with an require of "phpoffice/phpexcel". And unfortunately seems the problem is not only with me.

We can see on Packagist, using this url: https://packagist.org/search/?q=phpexcel, that 1 (one) install has done with the official package, phpoffice/phpexcel (it was me, after almost one hour!!!). Meanwhile the forks phpexcel/phpexcel and CodePlex/PHPExcel have a good number of installs (at work in fact I'm using the CodePlex/PHPExcel while the official is not completed).

I know that the official composer support was just added, but it's not the point: the SIZE of repository, IMHO, is the responsible for this issue.

Both the forks are using the same approach: provide via composer just the directory Classes, where is located the real library, and let the documentation and examples aside.

I think the library should not be separated from unit tests, they should be kept in the same repo (further when using TDD or TAD, allowing the contributors to still send patches with related unit tests). But the docs maybe be kept on an aside repo just for that.

• Total size repo: 25.3 MB
  
• .git folder: 16.7 MB
• Examples folder: 3.2 MB
• Documentation folder: 2.7 MB
• Classes folder: 3.6 MB
• unitTests folder: 258 KB
• Build folder: 12 KB
• other files: 143 KB

My suggestion is:

• create a new repository (or maybe rename this) to PHPExcel-docs (as made on https://github.com/symfony/symfony-docs https://github.com/zendframework/zf2-documentation, where there are different repositories to maintain the documentation and the code)
• create a new repository, only with the code and the unit tests (that repo should have the git itself cleaned, to make the total size in MB of the repo smaller).

I think this would solve the problem with composer install timeout (because the source code would be smaller), the issue #1, providing a way to get just what some persons need even if they don't want to use PEAR, or the CodePlex link, and it's related with issues #62 and #52 as well.

What do you guys think about that?

[Aeon]

👍 would love to be able to use the official repository in composer.

[bretrzaun]

+1

[rogeriopradoj]

Hi, @MarkBaker, I think your commit 4779025 is a very good start, thanks for taking a look at this issue!

But the users will just be able to get the goods from it when the project release the next version, and, very important, only with a version tag that Composer and Packagist can handle.

For example, if the next version get the tag name 1.7.9, Composer and Packagist will be able to point this version in, awesome. But, if you go instead with PHPExcel_1.7.9 the install will be get from the source, invalidating the point of .gitattributes.

Composer doc says:

Tags

For every tag that looks like a version, a package version of that tag will be created. It should match 'X.Y.Z' or >'vX.Y.Z', with an optional suffix for RC, beta, alpha or patch.

Here are a few examples of valid tag names:

1.0.0
v1.0.0
1.10.5-RC1
v4.4.4beta2
v2.0.0-alpha
v2.0.4-p1

And keep going:

Branches
For every branch, a package development version will be created.[...]
[...]Note: When you install a dev version, it will install it from source.

That's the reason when we visit https://packagist.org/packages/phpoffice/phpexcel we just see composer package versions dev-develop, dev-calcengine and so on (dev-versions always install from the source, not getting the benefit of your commit...).

---

And a thing for future, I wish, could be this project following the Semantic Versioning to name releases, as Composer suggests as well.