[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