[wp-trac] [WordPress Trac] #23912: Add Composer package description

[WordPress Trac]

#23912: Add Composer package description
-------------------------+-----------------------------
 Reporter:  Rarst        |       Owner:
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Future Release
Component:  General      |     Version:  3.5
 Severity:  trivial      |  Resolution:
 Keywords:               |
-------------------------+-----------------------------

Comment (by JohnPBloch):

 Replying to [comment:69 bpetty]:
 > No-one is saying you can build WordPress sites without WordPress, we're
 saying that WordPress is an application, not a library, and as such, it
 can't be defined as a dependency because if you use Composer to install
 WordPress, you're supposed to do so using the `create-project` command,
 and defining your extra plugin dependencies in your local `composer.json`
 file.

 That is how ''you'' would install it. I install WordPress in a
 subdirectory a la Jaquith's WP Skeleton set-up. When I deploy a WordPress
 site, the ''site'' is the main package, with WordPress usually two
 directories deep (`webroot/wp`). Using `composer create-project` makes no
 sense at all for that workflow. Running WordPress in a subdirectory has
 been a normal way of setting it up for a '''long''' time and has only
 become more so with the addition of support for multisite in a
 subdirectory.

 I have a personally maintained fork of WordPress with a `composer.json`
 file added on packagist. Go to your terminal and type `composer create-
 project johnpbloch/wordpress:~3.8 wp38` and you'll have WordPress core in
 `wp38`. The WP-as-a-library way of thinking supports your use-case of WP-
 as-root-package-only, but your approach precludes our way of using it
 (including the WP-in-a-subdirectory installation).

 > They even note that "core no longer pretends to be a component that is
 installable via composer. This never worked, and core will need to be
 modified in several ways before this can work." This is exactly the same
 situation WordPress is in.

 Preposterous. This is not at all the situation WordPress is in. I
 currently deploy several sites with composer and all of them do so

 1. With WordPress as a dependency of the main site package
 2. Without modifying any core file

 This is possible ''because'' core has made it possible for WordPress to
 redefine where `wp-content` is and to look one directory up for `wp-
 config.php`.

 > Requiring a custom Composer installer would be moving in the opposite
 direction of other platforms, no-one else is doing it (with the intention
 of using it as a permanent, widely distributed, and encouraged solution),
 and it's entirely non-standard. We wouldn't be defining any "new
 standard", we'd just be the weird project using Composer in a way that it
 wasn't designed to be used.

 To be fair, we're also the weird project that still supports back to PHP
 5.2 and doesn't care what the PHP community thinks in any other area EVER.
 So it's kind of silly that we seem to care here suddenly.
 ----
 Ok. So let's revive the talks about adding a `composer.json`. I'm fine
 with that.

 It'd be trivial to create a meta package that required both the core
 package and a core installer, so I am 100% on board with dropping the core
 installer as a requirement in the core `composer.json` file. If we drop
 that requirement, I'd ask that the `type` be kept as `wordpress-core`.

 Regarding the placement of the `composer.json` file: I think that it needs
 to be a sibling to `wp-content`, `wp-includes`, `wp-admin`, etc. Automated
 repository parsers should be able to find things without being told how
 and that means using the traditional svn structure found in
 core.svn.wordpress.org. Which means the composer file needs to be in
 `/trunk` and all future `/branch/X` and `/tag/X` directories in
 http://core.svn.wordpress.org.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/23912#comment:70>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform