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

Tue Jan 21 00:18:00 UTC 2014

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

 Replying to [comment:87 bpetty]:
 >
 > 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.

 RPM, Deb, apt-get, aptitude, synaptic, homebrew, there are quite a few
 tools, some decades old, that do exactly that. There is even greater
 precedent for this than for doing it with libraries. These tools help
 define an environment.
 > >  - 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.

 I do not have a forked repo of WP Core and have no desire to. Composer
 reads the appropriate repositories for information on versions and
 branches. I also have no desire for a wp-admin or wp-includes that can be
 written from a web accessible/ran script. This is a security concern, and
 one that clients and server administrators have and will point it in
 future if it's allowed.

 I can appreciate that this is not normal, but it is done by a nontrivial
 number of people, and offers significant security benefits.

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

 People can already 'abuse' WordPress core using composer without any
 composer.json at all, be it via VCS externals, or manually defined
 packages in the remote composer.json. I could declare in my satis repo
 that WordPress is of type drupal-core if I wish, it will happen, and there
 is nothing you can do to stop it. Having said that I would be foolish to
 do so. This is a slippery slope argument and mostly unfounded. The people
 who will do what you fear are already doing it.

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

 I have faith the core developers will not suddenly change composer.json
 and the folder structure on a whim, and just because composer can do it,
 doesn't mean we should or will.

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

 SVN won't tell me if my plugin dependency needs WordPress 3.9 developer
 but only 3.8 stable is available. SVN won't let me upgrade to any
 arbitrary version of a plugin between 2.3 and 2.6 without needing the
 plugin author to maintain a branch. SVN won't tell me when a theme
 declares that it is incompatible with a plugin. SVN has its limitations,
 and SVN externals and composer dependency management are not equivalant.

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

 Composer does not activate plugins, it merely installs them. Activation
 and deactivation hooks etc are still present and will still run. What kind
 of plugin would run a database migration on installation prior to its
 activation? Or execute any code prior to activation? I would be very wary
 of such plugins, using the built in installer or not.

 The only case you could put forward here is uninstall/deletion hooks, but
 even then, Johns core installer wouldn't do this because his core
 installer is not for installing plugins and themes, it's for installing WP
 Core.

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

 I don't think you grasped what I was trying to say. Composer is a
 developer tool, a Command line tool, how does this open us up to a
 userbase of non developers?  I doubt a non-developer would be able to
 write their composer.json, fire up a terminal, change to the right folder,
 and plug in the appropriate commands and parameters. It makes no sense.

  > There's good reasons for having two composer.json files because we have
 two root folders for WP: (1) the root of develop.svn.wordpress.org/trunk,
 and (2) the root of core.svn.wordpress.org/trunk (or just
 develop.svn.wordpress.org/trunk/build if you prefer to think about it that
 way).

 I agree, there should be 2 separate composer.json files because of the
 differing folder layouts. We should only concern ourselves with the
 core.svn.wordpress.org composer.json here. develop.svn.wordpress.org has a
 different purpose, and the suggested and required packages may differ, it
 should be discussed in a new ticket.

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