Is there a way to redirect users to packagist version instead of using wpackagist?

[jtsternberg]

We actively manage the CMB2 packagist repo and occasionally have issues with users who are using wppackagist. Do you provide any solution to this issue?

[joaquimds]

Unfortunately we only support SVN tags at this time, as this is what wordpress.org uses in its plugin directory. Am I right in thinking that previous releases aren't tagged in your SVN repository? If so, you may need to manually tag old releases.

[jtsternberg]

Yes, we avoid pushing old tags to svn. We prefer to manage through git and packagist. I’d recommend offering some CLI output or something when plugins in the WP repo would prefer for users to use a different composer repo.

[khromov]

@jtsternberg Any reason why you don't want to push to the SVN tags? It would surely be a minor change to any automation you currently have in place.

I think you're breaking other things than just WPackagist with your current approach, as the wporg repo has no way of preserving old versions of plugins if you just commit to trunk/. (Unlike a normal Git repo where you can lock by a specific commit hash.)

I'm not actually sure a repo can even send a message to the user, I thought that could only be handled on the package level via post-install-cmd / post-update-cmd commands... You are welcome to make a PR to this repo if you find a way but there's a bigger discussion to it.

[jtsternberg]

The only things breaking are the things which are relying on the svn tag structure, which we don't maintain. We maintain a git tag structure.

Saying "it would surely be a minor change" to another open-source maintainer is a bit ironic. It's a bit like saying "wpackagist honoring plugins which host their composer package with packagist would surely be a minor change".

It's certainly possible it's minor.

[joaquimds]

WordPress plugins are very much tied to the SVN version control system, as this is how Wordpress.org maintains their plugin database. WPackagist uses the https://plugins.svn.wordpress.org/ endpoint to retrieve all plugins and their versions, and as far as I know there is no Git equivalent. Ideally Wordpress.org would provide this – it would indeed make Git version support in WPackagist trivial.

We could potentially search https://packagist.org for packages with the same name as the WordPress plugin, and include the versions found there in WPackagist, but this would be a major new feature, and may not be particularly reliable.

As for displaying a message to a user if the package should use the https://packagist.org repository – I'm not sure how this could be done by WPackagist. Looking at this composer issue, it seems like composer doesn't support running post-install scripts when a package is installed as a dependency, and they seem to have good reasons for doing this.

One way this issue could be "solved" is by embedding the packagist.org repository in the information returned by the WPorg client. You could do this by tagging your plugin on WPorg with packagist.org/packages/webdevstudios/cmb2. WPackagist could detect tags that start with (https?://)?packagist.org and assume that they point to the plugin's packagist page. Then, instead of showing the versions in https://wpackagist.org, we would display a link to the packagist repository.

[khromov]

@jtsternberg I can't find the code where (if?) you automate syncing between Git and SVN, but the entire task would be to copy the trunk into tags/<CURRENT_TAG> before committing to SVN.

Something like:

cp -Rfv /trunk /tags/$current_tag

I think, you are not making a serious argument if you compare the above with implementing an entirely new featureset in this project, but I invite you to try to do it with a one-liner. 😆