[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:  3.7
Component:  General                 |     Version:  3.5
 Severity:  trivial                 |  Resolution:
 Keywords:  has-patch dev-feedback  |
------------------------------------+------------------

Comment (by bpetty):

 Back in comment:10, you were advocating keeping things simple just
 initially here without any extra dependencies on the Composer stack, or
 worrying about installer paths for now. That doesn't appear to be the case
 anymore.

 I still feel like it would be a mistake adding a dependency on
 composer/installers right off the start, as well as abusing the
 "wordpress-plugin" type for a package it was not designed to be used for.

 Using the "wordpress-plugin" type for core itself would end up requiring
 developers and admins using the package as a dependency to absolutely
 specify an installation path (even if it's fine in the default vendor
 path) since otherwise, it will be treated like a plugin and installed in
 "wp-content/plugins". Sure, this is easy to do, and I can't currently
 think of a situation where it wouldn't be possible to customize, but it
 still results in a terrible default behavior.

 Honestly, anything requiring a webroot should never be used as a package
 dependency to begin with. It's always your base software you're
 installing, and as your Composer project root, it will always be in the
 root path of your specified installation directory (either manually
 installed there, or by using "composer create-project" in most
 situations). Defining a composer/installers "type" certainly isn't going
 to effect that at all, but it would download and install
 composer/installers even if it's not in use, and placing it within your
 webroot every time. Of course, if you're using this with plugins (and if
 you're using Composer, chances are pretty good that you are), it will
 require composer/installers anyway until WordPress supports traditional
 Composer packages itself (not just 3rd party libraries but also plugins),
 so probably no harm in either case. However, why make that decision in the
 base package? Hopefully at some point in the future, composer/installers
 is never required even for plugins and themes. The composer/installers
 package is only designed to be a transitional package, not for the purpose
 of building new architecture intentionally designed to be a crutch for all
 future use.

 Anyway, the issues surrounding this decision are complex, which is exactly
 why I was agreeing with your first comment (comment:10) in regards to
 ignoring this for now, and just getting a basic composer package file in
 place with appropriate meta data, and appropriate PHP version dependency
 information. Can we at least agree on that, and push the
 composer/installers dependency back to a new ticket that can be evaluated
 when we also have the time to investigate possible solutions to including
 3rd party composer libraries through the autoloader? We have to handle
 that eventually too, and it has some relevance to the composer/installers
 approach.

--
Ticket URL: <http://core.trac.wordpress.org/ticket/23912#comment:20>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software