Add a virtual package for WordPress core?

[gmazzap]

At the moment, best way to have WordPress sites entirely managed with Composer is to use this package.

And according to Packagist stats, it's also the de facto standard way to do that.

So, first of all, thanks.

Today, for first time, I've worked on a package that make sense to use only in WordPress sites entirely managed via Composer.

So I thought was fine to state in composer.json it requires WordPress.

Now, once WordPress has not it's own official Composer package, at least not yet, the only way to do that would be to add johnpbloch/wordpress among the dependencies of my package.

I have nothing against your name :), but that doesn't seem right to me.

In fact, my package can work with any composer package that provides WordPress, so requiring your specific package I think it's wrong.

This is the reason IMO it worth to start using a virtual package "wordpress/wordpress" by adding it to provide setting of this package.

That way, packages intended to be used in sites entirely managed via Composer, can add that virtual package in their require setting.

And that requirement will be satisfied by your package or by any other package that will declare to provide WordPress.

If one day WordPress will natively support Composer, all packages that had declared a dependency from "wordpress/wordpress" will continue to work without any change.

Opinions?

[johnpbloch]

:+1: for the proposal in general (rely on abstractions instead of concretions). I will have to think about the specific proposal of using "wordpress/wordpress" as the virtual package name. I'm inclined to say we should use something else.

My main concern comes from uncertainty about how "provides" works. For example if my site requires my WP package and your package (which requires the virtual package), should core release a package w/ the same name as the virtual package, will my site now require 2 instances of core?

[mnapoli]

I think it shouldn't use wordpress/wordpress if this is not the official repository.

[gmazzap]

@mnapoli Problem is it doesn't exist any official repository. And who knows if it will ever exist. That's why I'm suggesting to use that name in provide (not as the package name).

I think this repo is the only one that has the numbers to establish a standard for a virtual WordPress alias.

I've suggested wordpress/wordpress because in the official trac ticket that's the name that was proposed by @rarst (2 years ago) for a WordPress official package. I don't know if you're familiar with WordPress trac system, but things can stay open there for decades...

Surely, we can use a different name for the virtual package, but in that case if WordPress will ever officially support Composer all the packages that had required that virtual package need to be updated. Unless WP itself will also embrace that virtual package name invented by us, and that's not exactly easy.

@johnpbloch I'm not 100% sure, but I thinks that, yes, in that case your site will require 2 instances of core, unless that official release contains a replace link to your package.

If you want I can do some tests... (in the weekend).

However, consider that normally virtual packages are used for packages that doesn't really exists, if core will ever release a real package named wordpress/wordpress you should probably remove the provide entry in your composer.json...

And I would say that in case of official WordPress Composer support, this package will not make a lot of sense anymore...and you could mark it as "abandoned" in Packagist (or completely remove it) after having also marked it as replaced by official core package...

[mnapoli]

That's why I'm suggesting to use that name in provide (not as the package name).

Oh clever!

[johnpbloch]

I plan to continue updating this package from upstream until nobody is using it any more. Even if core releases an official composer package.

if WordPress will ever officially support Composer all the packages that had required that virtual package need to be updated.

Only if the providing package is gone. In which case they'd need to update their composer manifest anyway, since non-existent packages are un-meetable dependencies. This, to me, is highly preferable to maybe accidentally installing a second copy of core which could have quite unexpected consequences (as there's no way of knowing what a composer.json file would look like in core).

[gmazzap]

as there's no way of knowing what a composer.json file would look like in core

Of course that's the biggest problem.

If I understand well your opinion is:

• option 1: do nothing
• option 2: let's use something that isn't wordpress/wordpress

I prefer the second, but I'll survive the first :) and I'd love some other people opinion.

[johnpbloch]

My opinion is option 2 and only option 2 (of those 2, that is. I'm still persuadable regarding wordpress/wordpress). Using virtual packages is a great idea and I love it and it should definitely happen.

[gmazzap]

Nice. Let's see I can persuade you.

Let's assume we use wordpress/wordpress as virtual name.

If and when WordPress will release official Composer package you can replace provide with conflict.

That way a double core installation will be never possible and so people will be forced to switch from this package to official one. When no one use this anymore, you can just delete it from Packagist.

Note that when you remove a package from Packagist there there is the possibility to declare a package that replaces it.

[gmazzap]

Moreover, if people store their composer.lock file (that's pivotal in whole site Composer packages) they will be able to recreate their exact site state even if the switch from provide to conflict had happened meanwhile.

[Rarst]

Against.

wordpress/* vendor “belongs” to the WordPress project. It is pointless to make assumptions about it and outright problematic (in regards to unknown future) to actually use it.

While the situation isn't optimal, in my opinion it's acceptable. I think suggest block is perfectly passable option to recommend some version of WordPress package.

[gmazzap]

@Rarst there is no doubt that wordpress/* belongs to WordPress project, but IMO that has nothing to do with the fact that we may or not may use it in the provide block.

IMO provide make perfectly sense for things that you don't own, just like suggest and conflict. Even in the Composer docs they are all listed under "package links". And "link" don't implies ownership.

In real world, one of the most used provide usage is for PSR log. I counted 14 packages that uses psr/log-implementation and no one of them own PSR namespace.

Of course, in the outside-of-WordPress world, provide is used for interfaces, and not for implementations. However, to use Composer in WordPress we already do things that outside-of-WordPress people don't do for the simple reason that WP, as project, don't support Composer.

BTW I'm still fine with not using wordpress/wordpress but I think that if there is a standard for packages that provides WordPress (in the lack of WordPress providing itself), it will be a good thing for us as WP developers.

Finally, what should we use in the suggest block? johnpbloch/wordpress?

Let's assume a newbie user followed a tutorial on the internet that explains how to setup a custom WordPress Composer package (You know there are some). And then they requires a package that suggests johnpbloch/wordpress. If they adds johnpbloch/wordpress, as suggested, they now has 2 versions of WordPress core.

Should we suggest wordpress/wordpress? It's doable, but does it make sense suggesting something that doesn't exists neither as virtual package?

[Rarst]

Interesting, do you have a backstory and reasoning on psr/log-implementation ? Quick google didn't come up with anything but that page on Packagist.

[gmazzap]

I remember something I read on the topic, but can't find the article.

Summary is that being a set common interfaces, if in my packages I uses only methods from those interfaces (via DI) I can make use of any package that implements them, no need to require a specific implementation.

Only posts I found on the topic are:

• https://devedge.wordpress.com/2014/09/27/composer-and-virtual-packages/
• http://php-and-symfony.matthiasnoback.nl/2014/10/composer-provide-and-dependency-inversion/

the latter is pretty against the usage of provide, but at the end of the article he opens to some usage cases

[johnpbloch]

That's a good point that none of the packages providing psr/log-implementation own the psr vendor name. I'm all for using the wordpress vendor name.

However, to continue using that example, they also didn't claim to provide psr/log while PSR-3 was being voted on, nor (I imagine) would they sit idly by if FIG started discussing whether they should release a package named psr/log-implementation.

For virtual packages, it makes the most sense to me to use a name that more directly implies the virtual/general nature of the virtual package. If I saw someone using wordpress/wordpress I would assume it was an actual core package, not a virtual one. Something like wordpress/wordpress-implementation or wordpress/wordpress-core-package strikes me as much less confusing.

So two things:

1. wordpress/wordpress is totally out of the question in my mind if a core package being released would cause 2 copies of WP to be installed.
2. If only one copy of WP gets installed with no unexpected behavior, what are the pros and cons of using wordpress/wordpress? What are the pros and cons of using a more generalized virtual package name?

I'll work on some tests to see what happens in the scenario of a core package coming out.

[Rarst]

One other point I want to raise is that it might be WordPress environment without WordPress package. For example I have a mixed kind of install where some plugins are managed by Composer, but WordPress core is "normal" and manages itself.

Making core a hard requirement in some form would prevent package from working in such kind of install.

Overall I feel this is bit of a solution in search of a problem. The only thing we can't do right now is to require specific version of core package, that essentially doesn't actually exist anyway.

Is it so important of an issue to start piling up hacks to address it? It's not broken. :)

[johnpbloch]

Real quick, set up a test for what happens when a provided package gets added as a non-virtual one: https://gist.github.com/johnpbloch/b325aa2e93d92100c80d

Results: 3rd package gets installed as normal but doesn't interfere with providing package either.

[gmazzap]

@johnpbloch don't forget that conflict can be used to avoid 2 copies of WP to be installed in any case.

Regarding pros and cons I think that most of them are related to a future WordPress implementation of Composer. And once there is no way to know how it will ever be IMO is just matter of personal preference. And I don't actually have one: wordpress/wordpress or wordpress/wordpress-implementation or wordpress/whatever let me know what I've to use and I'll use it :)

@Rarst

Making core a hard requirement in some form would prevent package from working in such kind of install.

Of course. In my 1st post I said that it make sense only on packages intended to be used in sites entirely managed via Composer. And it's up to developer of the package add a require or not. And developer (should) know if it's the case.

BTW, even though I am pretty prolific I never wrote (untill yesterday) something like that :)

So, no, I don't think it is so important.

However, if we add a provide here it will not hurt this package nor any other packages, actually it will have no effect on the great majority of packages. But for the small part of packages that requires a full WordPress environment, being able to require WordPress will be -at least- interesting.

[QWp6t]

It seems like this is mostly a cosmetic thing, with you not wanting to use the johnpbloch namespace.

I'm unconvinced that this is necessary, but to each his own. Meh.

[johnpbloch]

@QWp6t I'm not getting the vibe that it's a cosmetic preference. I think it's more about flexibility in use. Virtual packages are a pretty useful feature of composer and one that (I think) fits the bill here.

Not strictly necessary, but still useful to some people without affecting anybody who doesn't want to use it.

[dzuelke]

... so? :) I'd love it if this package provided wordpress/wordpress, too =)

[johnpbloch]

I just submitted a PR to add this to the build routine: https://github.com/johnpbloch/build-wp/pull/3

Please take a look and add your comments over there.

[johnpbloch]

This has been added to the build script and the docker containers have been rebuilt. This will make its way into master the next time trunk gets updated and into the next round of tags/branches that get released. The virtual package is wordpress/core-implementation, and it is johnpbloch/wordpress-core that provides it, not this package.