[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:  Build Tools  |     Version:  3.5
 Severity:  trivial      |  Resolution:
 Keywords:               |
-------------------------+-----------------------------

Comment (by bpetty):

 Replying to [comment:70 JohnPBloch]:
 > That is how ''you'' would install it.

 It's how the official installation instructions tell users to install it.

 > 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.

 Normal, yes. Officially supported, yes. Officially recommended or more
 common though, no. In fact, I know this isn't how more than 5% of
 WordPress installations are installed because this isn't how users are
 instructed to install it, and it's not how any single-click installers
 provided by any hosting companies install it. It's also not the way
 WordPress is configured to run by default.

 Let's try and keep our primary user base in mind, and our primary user
 base isn't defining a custom `WP_CONTENT_DIR` setting with most
 installations.

 > 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.

 This is certainly one of the main reasons I'm also against the custom core
 installer requirement. It's perfectly possible to create 3rd party meta
 packages that overwrite the default package properties or installation
 routines for less common configurations. Both yourself and Rarst already
 have.

 > If we drop that requirement, I'd ask that the `type` be kept as
 `wordpress-core`.

 I feel like I'm running in circles on this one, but maybe I still have to
 remind everyone that the '''primary maintainer of the official Composer
 installer package''' has
 [https://github.com/composer/installers/issues/77#issuecomment-18417481
 recommended against doing this], and not just for WordPress (it's been
 requested several times before already with no progress either for
 `drupal-core` or for `fuel-core` as well). To quote him again:

 {{{
 #!div style="margin: 1em;"
 `core` types would exist for only 1 package where other types exist for
 many packages. I understand core types seem really useful but they seem
 problematic to me. As soon as 2 packages use the same core type it is
 going to blow up.
 }}}

 That's not meant to say that people aren't capable of being smart about
 not writing additional packages using the same `type`, but more meant to
 clarify that the `type` property was not designed to be used for this
 purpose, and that using it like this imposes limitations for developers
 building tools designed to work with it's original intended purpose. And
 again, he recommends the same thing I'm trying to make clear here:

 {{{
 #!div style="margin: 1em;"
 I'm also reluctant because it seems '''create-project exists to handle
 this use case'''.
 }}}

 It's obvious that using this `wordpress-core` type makes it possible to do
 things we couldn't before, but this isn't a question of what's possible,
 it's a question of what's appropriate. It's about using a properly
 designed architecture both for current use and for keeping future
 compatibility in mind in case WordPress ever makes the decision to
 redesign it's architecture in a way that's more "composer compatible" like
 many other projects have. If we make use of a custom `type` and/or a
 dependency on a custom installer, we're burning some of the bridges ahead
 of us that we might want to use in the future (or at the least, making it
 much more difficult to cross them).

 Right now, WordPress doesn't even support upgrading WordPress from
 Composer any more than it supports upgrading from VCS. It doesn't perform
 the same safety and security checks, it doesn't perform any DB migrations
 (and yes, I understand these will just happen on the next wp-admin request
 after an admin has been asked to), it doesn't call any plugin or theme
 hooks designed to be triggered by core (or plugin and theme) updates, and
 it doesn't flush any caches that should be flushed. It's not calling any
 core upgrader methods. It's hopefully true that most developers understand
 this when they manage WP updates from a VCS, and perform those tasks
 manually, but I want to stress that we should avoid giving users the
 impression that they can use Composer to manage upgrades for them just as
 reliably as using the built-in upgrader since offering Composer support
 opens that user base significantly to non-developers, who aren't using
 VCS, but are being exposed to those same developer-related limitations and
 problems.

 > 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.

 Yep. Not arguing that. My patch didn't include it there, but I did say
 that I think it should be there. I just want to see it done in a way that
 we avoid maintaining mostly duplicate package files in the develop root as
 well as the src root (i.e. building an automated grunt task that generates
 the src version from the main root package file with one simple package
 name change).

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