Integrating composer (Fixes #45)
This adds a composer.json for all dependencies that are available and the include_path manipulations for "extlib/" that is still required because some dependencies are not available for composer.
This also replaces the include_path manipulation with simple requiring the autoload file, removes some require statements that are replaced with the autoloader of the packages and remove the replaced dependencies in extlib.
Please test it. Everything I checked is working, but I neither know all features nor using all plugins ;)
I'm not familiar with how to use composer. Could you give a short introduction on what one has to do to use it?
I'm uncomfortable to have distribution of a complete software package to rely on proprietary sources like GitHub, which seems to be the case with PEAR packages for example. Because as I understand it the idea is to download packages via composer from some remote repository.
The idea of composer is to manager dependencies during development. This allows to remove the dependencies from the repository and still have reliable versions. Each developer can simply install all run-time and development deps with:
A release package should contain all the required dependencies. So just before building the release tar you should do something like this:
composer install --no-dev composer dump-autoload --optimize
This will remove all the development dependencies, but still keeps the required run-time libraries. After that the release-tar can be created and should not ignore the
vendor/directory. In that way, the release will be installable without any use of composer.
Additionally we could submit gnu-social on https://packagist.org and people can install it simply with composer.
The composer.json in this merge request is very simple. There are a lot of more fields (https://getcomposer.org/doc/04-schema.md) and if we want to submit a package of gnu-social it self, we maybe should add some other information (like authors, license, homepage, repository...).
Yeah, my point is however that "reliable versions" aren't very reliable if they're hosted on GitHub. Which at least the majority of packages linked in the composer files seem to be.
I wouldn't mind having the code adapted so it would be easy to maintain a "composer fork" of some kind, for example in order to maintain a package on packagist.org, but I don't think it's a good idea to rely on this distribution mechanism in our mainline package.
Besides, 'composer' doesn't seem to be available in neither any Ubuntu LTS nor Debian stable official repositories as far as I can see, so it wouldn't have very widespread support in the field.
The versions are referenced with the git commit hash. Shouldn't that provide enough security if some dependency silently change the version tag in the repository pointing to another version.
composer will be available in the next debian release (stretch) https://packages.debian.org/stretch/composer. But besides that, it is available as "php archive". You can either download it directly:
wget https://getcomposer.org/composer.phar php composer.phar
or install it with an installer that checks some required php settings and also downloads the phar https://getcomposer.org/doc/00-intro.md#installation-linux-unix-osx.
But I do not want to argue. I saw the issue and thought that I can fix it.
Here maybe some ideas what to do with composer (besides removing the dependencies from the repository):
- We could add a custom package type for plugins. So that plugins could be developed externally and automatically installed in the correct location.
- I thought, that it would be nice to replace the php-cli scripts in
scripts/with something like http://symfony.com/doc/current/components/console/introduction.html that would allow grouping the scripts in categories and nice and modern console-ui. We even could add an event, so that plugins could register some sub-commands and all this whould be executed (and discovered) from one script in the top level. But I do not like to dump the symfony-console dependency into the
I really appreciate this work: I had to update some external libraries as the upstream version were fixing problems I was experiencing, with something like this it will be a lot more easier!
But all the exlibs aren't in
$ROOT/extlib, here's what I found about the others:
- Jcrop, hosted on https://github.com/tapmodo/Jcrop. Provided: 0.9.12 (3 Feb 2013). Latest: v2.0.4 (18 Nov 2015)
- jQuery UI, hosted on https://jqueryui.com/. Provided: v1.11.3. Latest stable: v1.11.4.
- jquery-cookie (No longer maintained, superseded by JS Cookie: https://github.com/js-cookie/js-cookie), hosted on https://github.com/carhartl/jquery-cookie. Provided: latest stable, v1.4.1 (27 Apr 2014).
- jQuery Form Plugin, hosted on https://github.com/malsup/form. Provided: latest stable, 3.51 (3 Sep 2014).
- jQuery with Sizzle, hosted on https://code.jquery.com. Provided: 2.1.4, latest stable: 2.2.0.
- json2.js, hostend on https://github.com/douglascrockford/JSON-js. Provided: 2015-02-25, latest: 2015-05-03.
- XMPPHP. Code is no longer maintained and upstream SVN seems to be unavailable. Latest upstream: https://code.google.com/archive/p/xmpphp/downloads but there are forks / other projets still maintained (https://github.com/fabiang/xmpp) or just a git copy (https://github.com/heshanlk/XMPPHP)
- Wordpress Teams Integration's
teams-extension.php. Hosted on https://code.launchpad.net/wordpress-teams-integration. Last changed 2010-03-02.
- Wordpress Teams Integration's
- Moved to GitHub since Google Code's closing: https://github.com/mrclay/minify. Provided: 2.1.3 (before 10 Mar 2012). Latest: 2.2.1 (30 Oct 2014).
- Net_LDAP2. Pear package hosted on https://pear.php.net/package/Net_LDAP2. Provided: 2.1.0 (2013-12-09). Latest: 2.2.0 (2015-10-30).
- XML_XRD, hosted on https://pear.php.net/package/XML_XRD
- FirePHP, hosted on https://github.com/firephp/firephp-core. Latest: v0.4.0.
- Facebook SDK for PHP, hosted on https://github.com/facebookarchive/facebook-php-sdk. This SDK is deprecated.
- regdom-libs, no upstream found.
- Bayeux, no upstream found.
- CAS, hosted on https://developer.jasig.org/cas-clients/php/current/. Provided: 1.1.2. Latest: 1.3.4.
Is this handable by a composer.lock?
One option is to keep the
./vendordirectory under source control. That way, the project is not reliant on the continued existence of Github or any particular dependency's remote repo. Composer still provides benefits by allowing dependencies to be updated easily, isolated from the source code of the project itself, and nicer autoloading.
This is good work and we should accept it into the project.
Composer is widely used by PHP projects.
@postblue In my opinion the extlibs for the plugins should be handled with in the plugins itself. I thought of something like a custom composer type for gnu-social-plugins. So that even third party plugins, could be installed easily. The core could continue to ship a set of default plugins, that are also installable and upgradeable via composer.
The focus of this pull request is simple to replace most of the stuff in the extlib/ directory. I just saw, that the composer file can also include raw URLs to git repositories. So it might be possible to remove even more of the extlibs, that are currently not available on https://packagist.org.
@extropic-engine This would be a compromise. I would be ok with such a setup, too.
Other than the apparent merge conflict now, why have this not been merged yet?
@yookoala At least one very good reason is that since lots of packets rely on GitHub there is no way to reliably distribute the GNU social software.
One may at first of course argue that GitHub is a bad solution for Free/Libre software, as it is itself run on proprietary software. So no good in those aspects.
But one technical reason is that GitHub doesn't even support IPv6, so any IPv6-only hosts would be unable to retrieve the dependencies hosted there. I have experienced this very problematic issue with 'npm' for example, which relies extremely heavily on GitHub's benevolence.
...I am fully aware that git.gnu.io also only has an A record, but I do make sure that I keep up to date revisions on for example: https://notabug.org/gnu/social
composer does seem to have trickled into the package managers I use, so I can't use that as an argument anymore. But nevertheless, I think there's a point in distributing all source files at once, for archival purposes and ease of use to get stuff running.
closedToggle commit list
@mmn Using composer/packagist and the existing ecosystem of packages could help bring gnu/social forward and easier to use and maintain. I've demonstrated this by replacing the UUID class with a composer package.
You can commit to git the entire composer vendor directory, making GitHub and version compatibility issues irrelevant.