-
Notifications
You must be signed in to change notification settings - Fork 183
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
Remove development files from releases #276
Conversation
Nothing has changed here. The tests and docs belong in the release on principle: end-users need them. The whole purpose of the tests is to ensure that the thing runs on the user's system, right? And who else would the documentation be for? The Gentoo package will still work if you delete them from the release, since we install/run whatever is there, but the overall quality of the package will be reduced. I realize that composer just blindly copy/pastes all of this crap into your public webroot, but you shouldn't penalize the rest of us to make its retarded way of doing things slightly less retarded =P |
The reasoning behind considering these files as development ones is that they are not required in order to use the package. They are only required for development purposes and will be never used in runtime.
What points are you considering about the overall quality? |
But that's not true! The CI tests only two specific configurations. There's a huge (combinatorial, impossible to try them all) number of valid configurations. All matching versions of all dependencies, as well as of PHP itself, with yes/no for every optional PHP extension. Then there is the host machine to consider... it's architecture, how much RAM is available to PHP, what's in Allowing users to run the tests before they install the package ensures that they don't have an untested and broken configuration (this is all automatic in Gentoo, and the package install will fail if the tests fail).
I'm talking only about the quality of the release tarball, which composer conflates with the thing to be copied into your webroot. A priori, having the documentation and tests in the release tarball can only add to that quality; not harm it. The documentation is useful to some users, and does no harm to others. The tests are useful to everyone IMO, and do no harm to others. The sane way to install the (any) library is to put one copy, managed by the system, under PHP's |
I don't think testing a package against all the possible scenarios is impossible. IIUC, your perspective is about using this package through other dependency manager than Composer.
Tests are part of what you can be interested in before taking the decision of using some package, since it can help to be sure the quality is guaranteed.
Using the PHP's |
I'm sorry, but it's a mathematical fact. If there are
As above, this is impossible. Count how many optional extensions PHP has, call it
Every Linux package manager installs the documentation for its packages in a somewhat-standard place. You don't need a special "help" command because the help file is a plain text file located at |
I don't know why we should check this package against setups using extensions not declared as a dependency.
That's fine for me. If it helps users using Linux package managers, I'll update the PR to keep the |
Any news here? Please note: The PR targets the (meanwhile) unsupported |
Target branch updated. Thank you. |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## v2.x #276 +/- ##
=========================================
Coverage 98.53% 98.53%
Complexity 631 631
=========================================
Files 29 29
Lines 1905 1905
=========================================
Hits 1877 1877
Misses 28 28 ☔ View full report in Codecov by Sentry. |
No description provided.