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

WordPress Trac noreply at wordpress.org
Mon Aug 5 19:04:41 UTC 2013


#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 Rarst):

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

 Yes, which was two months and a lot of exploration ago. That is still an
 option of course, but it fixes WP core to the vendor directory which is
 considerably limiting.

 > I still feel like it would be a mistake adding a dependency on
 composer/installers right off the start

 Since any Composer-driven WP project will probably need
 `composer/installers` for every theme and plugin, it's not really out of
 line requirement.

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

 I don't disagree, I am just trying to lay out a all the options and come
 to one that would be reasonably workable both from perspective of Composer
 as tool and from perspective of core actually adopting it.

 > Honestly, anything requiring a webroot should never be used as a package
 dependency to begin with.

 I am not aiming for webroot usage, I am aiming for subdirectory install
 (in WP terms) / package with custom path requirement (Composer terms).
 Subdir install is already de-facto preferable for any serious site, since
 it cleanly isolates core from all the other things.

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

 I could live with that, but my current opinion that it will not actually
 move WP usage with Composer forward. It's the very start of 3.7 cycle and
 this was put on agenda right away, I think some time to ponder it we have.

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

 If I remember right autoloaders in core are not being considered as long
 as 5.2 compat is the target (argument is that SPL might be disabled).

 In a nutshell I am trying to provide as much information and options as I
 can. It's up to core team to choose which level (if any) of Composer
 compatibility to set as target(s).

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


More information about the wp-trac mailing list