Optionally exclude a package's tests and docs

[skyzyx]

I'm writing some offline software in PHP, and it would be helpful if projects could notate where their source, test and doc directories are so that downstream consumers can choose a --source-only option in an effort to reduce the size of the resulting download.

[naderman]

You can do so with an export-ignore git attribute if you want or with an archive exclude which only applies to satis generated packages for the moment however: http://getcomposer.org/doc/04-schema.md#archive as we rely on github to generate packages for packagist.

Generally speaking the user of your library might want to run tests too, and a little bit of disk space is unlikely to be a big issue.

[skyzyx]

You can do so with an export-ignore git attribute if you want or with an archive exclude which only applies to satis generated packages for the moment however: http://getcomposer.org/doc/04-schema.md#archive as we rely on github to generate packages for packagist.

Do downstream consumers have the ability to configure this?

Generally speaking the user of your library might want to run tests too, and a little bit of disk space is unlikely to be a big issue.

I'm using Composer in a desktop app. And yes, 700kb vs. 2.5 MB is a big enough issue. No, they will never, ever run the tests.

[Seldaek]

As a package consumer you can't ignore tests automatically. I think your best bet is to clean up the vendor dir as part of your application build process. It's gonna be manual and a bit boring, but you can take inspiration from https://github.com/sensio/SensioDistributionBundle/blob/master/Resources/bin/build.sh#L54-80

[skyzyx]

I appreciate the direction and help. Thanks!

[c960657]

FWIW, the PEAR installer classifies the individual files as either PHP, documentation, tests, examples etc.:
http://pear.php.net/manual/en/guide.developers.package2.file.php#guide.developers.package2.file.roles

Linux packages (RPM/.deb) are traditionally split into different packages for binaries, source packages, header files (-dev packages for compiling against a library) and sometimes documentation.

You could imagine e.g. the Doctrine ORM package being split into these separate packages, possibly with a "suggest" link between them:

"suggest": {
    "doctrine/orm": "Doctrine Object-Relational-Mapper for PHP",
    "doctrine/orm-tests": "PHPUnit tests for Doctrine ORM",
    "doctrine/orm-docs-source": "Sphinx documentation files for Doctrine ORM",
    "doctrine/orm-docs": "Documentation for Doctrine ORM in PDF and HTML"
}

The tests package could have a dependency on PHPUnit, and the docs package could have a dependency on the Sphinx-to-HTML compiler.

[Frug]

"FWIW, the PEAR installer classifies the individual files as either PHP, documentation, tests, examples etc.:"

This seems very logical to me and maintaining deployment cleanup scripts to remove tests is not ideal.

[andyfeller]

The spirit of composer is a central authority of what is necessary for an application / project. Having to keep your deployment process in sync with composer changes to clean up undesirables doesn't feel right. Will look into using the archive exclude option for now but would be nice to have no brainer approach.

[jmkgreen]

I think it's because of this that my IDE is now refusing to open my project that now includes vendor modules and their dozens (at least) of test files which it is reporting OutOfMemory exceptions trying to parse. Clearly not the intention.

[Seldaek]

@jmkgreen most IDEs allow you to ignore folders, and probably ignoring vendor would be a thing, or vendor/*/*/test and vendor/*/*/tests if you can do wildcard

[andyfeller]

Our problem is mostly about keeping production releases as small as we can. Zend Framework uses 90 MB+ for documentation and test while 50 MB for actual source. Consider this is 1 of several libraries along with source code and binaries that need to be deployed on 30+ servers and the cost adds up. That is only keeping 1 code release on machines so it is even more of an issue for those who keep multiple versions for rollback purposes. This becomes even more challenging as everyone is moving to virtualized infrastructure and keeping VMs reasonably lean on resources.

Needless to say it isn't just a little bit of disk space and people have some real use cases.

[jmkgreen]

That's a step I I'd prefer to avoid - I would have to communicate that to other members particularly those on other ides or projects that deliberately exclude IDE configuration.

Our use case is that composer provides dependencies for our project. We have absolutely no requirement to hack on these dependencies - if we did it would be in a separate checkout.

Our experience of maven is superior here - declare a dependency and only the binary requirements are downloaded - the developer is then free to download javadoc and source code if they wish often with a right-click inside IDE. Even then tests don't don't come without expressly downloading the sources from the project website.

Downloading only the sources of a dependency is the default behaviour I would expect. It should be possible to download documentation but I'm struggling the see the value of this whole inside "our" application. If I want tests, that's a totally separate workflow process. It involving "our" app at all.

Sent from my iPad

On 4 Oct 2014, at 11:48, Jordi Boggiano notifications@github.com wrote:

@jmkgreen most IDEs allow you to ignore folders, and probably ignoring vendor would be a thing, or vendor///test and vendor///tests if you can do wildcard

—
Reply to this email directly or view it on GitHub.

[malkusch]

+1 for having relevant sources only.

The irrelevant files (mainly tests) are significantly polluting the IDE's memory which makes it unenjoyable to develop. Sadly the archive/exclude is not an option for this use case.

[joecomstock]

I would also add that a good number of libs trigger issues of variable severity when run through a static analysis tool due to testing code, so those of us that use composer for projects in e-commerce and have security requirements to meet would really love this feature.

[skyzyx]

At worst, why not just write a Composer post-install hook to remove what you don't want?