[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:79 TJNowell]:
 > There's a fundamental misunderstanding here, we're not discussing
 WordPress as a code library to be integrated into another piece of code.

 Right, that's why we're saying it's not a dependency whose updates can be
 managed by composer, and shouldn't be treated like one (at least, by
 default anyway). This is how '''libraries''' are managed, not
 applications.

 > E.g. if the package example/example.com depends on wordpress/wordpress
 and wordpress/akismet, and its repository contains a wp-config.php and a
 htaccess, how is this bad? There's no output buffer library binding
 trickery being employed,''' the end result is a standard WordPress subdir
 install'''
 >
 > Using Rarsts/Johns composer.json this is perfectly fine.

 And this also still works with my proposed composer.json, it just requires
 an extra meta-package to implement your customizations to do this non-
 standard installation.

 >  - the example.com maintainer would be forced to use a classic install,
 a subdirectory install via composer is no longer an option

 This is still possible.

 >  - example.com can still update their theme and plugin packages, but if
 say wordpress 3.9 stable was released, they need to checkout, setup, run
 the updater, commit changes, push back to original source, etc, etc The
 ability to update and maintain versions of WP Core in a managed way is
 lost

 You're installed copy of WP will already contain the official core updater
 as usual, which is great because even if you're using John's custom
 installer, you're still seeing wp-admin upgrade notifications and
 functionality that still works as intended (which could even confuse
 Composer) as long as your files are writable (i.e. all shared hosting for
 one). And if you're implying that you're managing your own updates via
 your own commits from the official packages, you're saying you already
 have your own forked repo (which you were arguing against doing at the end
 here... so your argument is confusing here), in which case, this is
 definitely still perfectly possible even without a custom installer.


 Replying to [comment:81 TJNowell]:
 >  > 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.
 >
 > In which case it's just as appropriate as using git submodules and
 externals. Also keep in mind that clients can demand these kinds of
 installs, and there are real advantages to putting WP Core in its own
 folder.

 I'm not arguing the merits of subfolder installations. I'm arguing the
 merits of abusing Composer package properties for purposes they weren't
 designed to be used for, and what that means for future changes.

 > I fail to see how wordpress-core will be an issue. If in future we
 change the composer.json to 'moomin-spectacular', composer will re-arrange
 things as necessary into the vendor folder

 A default installation directory change on update is by far one of the
 biggest backwards incompatible changes we could possibly make. Why do you
 think we went through so much work building an entirely new SVN repository
 for core rather than just moving all of WP into a `src` subdirectory on
 `core.svn.wordpress.org`?

 >  > Right now, WordPress doesn't even support upgrading WordPress from
 >  > Composer any more than it supports upgrading from VCS.
 >
 > Actually that's not true. I can say that I need WordPress in my sites
 composer, specifically stable WordPress, and only the 3.8.x branch. I can
 specify that I want an exact version, or that I want developer builds, and
 I can say in my plugins that they need a specific version of WordPress,
 and composer will handle all of this. Git submodules do not. SVN Externals
 do not.

 I think you missed my point here, and I'm really not sure where you went
 with it.

 P.S. SVN externals do support that though.

 > Neither do svn/git updates, FTP'ing plugins manually, rsync, or
 extracting zip archives over the top of the filesystem.

 Exactly, but we still encourage users to upgrade through wp-admin first
 when possible. When using WP as a composer dependency though, you're
 telling users not to, even when they could be upgrading through wp-admin
 (and we're still spitting out upgrade notices to them in the admin panel,
 just contradicting own recommendations at that point).

 > The difference here is that composer has a scripts section that can load
 a WordPress environment and do the necessary work. As a user of Johns
 composer installer, this has never been an issue

 This is exactly what I mean. I'm assuming you would even call yourself a
 "developer", but you've just made the same mistake I expect regular users
 will constantly make. I've been through John's custom installer code and
 patches extensively, and while you're right that it's possible to trigger
 [http://getcomposer.org/doc/articles/scripts.md all sorts of scripts] on
 install/update, not even John's package does any of the above. If you
 didn't manually flush any object caches, trigger DB migrations, or trigger
 your installed plugin/theme upgrade hooks manually, your installation was
 not officially in a properly upgraded state. WP usually finds ways around
 most of this without causing serious errors or problems (like you said,
 users do this all the time already with FTP/ZIPs), but these are
 '''supposed''' to happen, and they don't if you upgraded using John's
 composer package file.

 > So your argument is that by adding a file to enable the use of a
 developer-centric command line tool, we're opening ourselves up to a
 significant userbase of non-developers.

 It's just one additional supporting claim, not my primary reason though.

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