Rename Package for Composer/Packagist

jrfnl commented 2 years ago

Follow up on #113 and #146, which contain mentions/discussions about this as well.

Now the repository has moved to the PHPCSStandards organisation and been renamed to composer-installer, the question arises whether or not to rename the Composer package too.

Currently the Composer package name is: dealerdirect/phpcodesniffer-composer-installer

The proposed new Composer package name would be: phpcsstandards/composer-installer (in line with the new repo home)

Advantages:

Predictability of the name/Findability of the new repo home
Control over the package information in Packagist without a dependency on the DealerDirect organisation.

Disadvantages:

Loss of the statistics on Packagist (24M downloads and counting)
Code churn for the 30.000+ repositories using this package. It may take years before all users have moved over ~~and users may not benefit of improvements made in the package until they have updated their composer.json config~~ (looks like the old package will still update).
- Each of these would need to "allow" the new plugin for Composer 2.2+.
- For those repositories for which this package is a root dependency, the dependency would need to be updated too.

If it would be decided to rename the package, this link was mentioned by @GaryJones in #113 containing information on how to manage this on the Packagist side of things: https://github.com/composer/packagist/issues/47

Tasks if the package would be renamed:

[ ] See https://github.com/composer/packagist/issues/47 for the Packagist side of things
[ ] Fix/update all references to the package name in the repo
[ ] Update the namespace of the code ?

Potherca commented 2 years ago

Loss of the statistics on Packagist (24M downloads and counting)

I'm willing to take a 24M hit as, looking at the stats, I think we'll be back on that number in a year or two anyway.

Code churn for the repositories using this package

Each of these would need to "allow" the new plugin for Composer 2.2+.

I haven't done a proof-of-concept for this so I don't know how viable an idea this is, but could a complementary or intermediate solution be to make the old package a metapackage (including only the renamed package) after the rename?

That would at least resolve the issue regarding repositories for which this package is a root dependency, although I think they would still need to "allow" the new plugin.

It would also give us an idea (through stats) how many packages still use the old name.

jrfnl commented 2 years ago

I haven't done a proof-of-concept for this so I don't know how viable an idea this is, but could a complementary or intermediate solution be to make the old package a metapackage (including only the renamed package) after the rename?

I'm not entirely sure what you mean by that, though I seem to recall some discussion on this in one of the threads regarding renaming in the Packagist repo.

You may want to have a read through those:

jrfnl commented 2 years ago

It would also give us an idea (through stats) how many packages still use the old name.

Note - using the current official procedure a second (new) package would be created for the new name. The old name would be marked as abandoned with replacement.

As the old package name still exists, the stats will still update and we will still be able to see how many packages use the old name.

To illustrate:

For perspective regarding the stats, the rename of PHPCompatibility was done in version 8.2.0 / July 2018.

As a lot of repos "inherit" the dependency via an external standard, we could try to help smooth over the transition by sending in some PRs to some of the bigger packages which require this package.

While that would help a lot in moving users to the new package, each "end-user" package would still need to update the "allow-plugins" configuration.

jrfnl commented 2 years ago

Open question: if we do rename the package, do we also want to rename the namespace ?

Potherca commented 2 years ago

One the one hand I don't see much need for it, on the other hand its just the one file (not counting test files) :shrug:

jrfnl commented 2 years ago

Well, the argumentation for doing so would be largely the same as the argumentation for changing the Composer package name: consistency, identity and findability.

Potherca commented 2 years ago

Okay... so what I originally intended with my meta-package idea was this:

In the current situation, we have one repo (on GitHub) and one package (on Packagist)

After deprecating the original package and creating a new package (on Packagist) that points to the existing repo, we would create a meta-package in a new repo and point the original package to the new repo:

Users that require the original package would automatically get the new one... Only, that wouldn't work as the type needs to be composer-plugin, otherwise nothing happens. So that idea has gone out the window. :disappointed:

Something similar could be done, keeping the composer-plugin type by making the original package a wrapper for the new package but that seems like more work than its worth.

Drawing the diagram did point out that "consistency" issue to me, so yeah, lets change the namespace as well. Otherwise things might be confusing to users not familiar with the projects history. :+1:

jrfnl commented 2 years ago

Copying over my comment about this from https://github.com/PHPCSStandards/composer-installer/issues/187#issuecomment-1219428851 for visibility:

If we action this, I'd favour doing so just before the 1.0 release as people would need to update their composer.json anyway to allow for the 1.0 version. Note: current download count the project would "lose" is > 36M.

Then again, what with the changes in Composer 2.2, I'm not sure we should action this at all, as the burden on end-users is now exponentially larger if we change this.

Originally, only people who would require[-dev] the plugin would need to make a change. If projects inherited the use of the plugin via one or more of the external PHPCS standards they use, the name change would not require action on their side (only on the side of the external PHPCS standard).

Since Composer 2.2, any project using this plugin - whether they require[-dev] it directly or inherit it from an external standard - needs to have the config - allow-plugins directive in their composer.json for this plugin. As the config - allow-plugins directive is package-name-based, those allow-plugins configs would ALL need to be updated on a name change, so the end-user impact/burden on maintainers is now much much larger. Based on the dependency-graph, this would now impact > 42K projects and that's only the projects which are public and published on GitHub, so the real number of projects which would be affected by this change is likely to be double that or more.

I would say that this is a "now or never" decision and taking the above into account, I lean towards "never".

fredden commented 1 year ago

To be honest, as the impact on end-users of a package rename is HUGE, that probably won't happen.

Some of this can be mitigated by moving this to the new name, and creating a meta-package at the old name that requires the new package. Something like:

{
    "name": "old/name",
    "description": "Transition package to aid migrating to new/name",
    "type": "metapackage",
    "require": {
        "new/name": "^1.0"
    },
    "abandonned": "new/name"
}

jrfnl commented 1 year ago

@fredden Thanks for pitching in. Unfortunately, AFAICS, such a construct is not going to help much.

While renaming the package in require[-dev] will be a pain for people, that is not the main pain-point as a lot of projects "inherit" the plugin with external PHPCS standards, so the amount of packages in which this needs to be changed is limited.

The biggest end-user impact of a rename would be that every project which directly or indirectly requires the plugin, will have to update the allow-plugins directive in their composer.json for the new name. That will affect a much larger amount of end-users and AFAIK, a meta package will not help with that.

fredden commented 1 year ago

Yes, I can see the main pain-point will be allow-plugins which a meta-package won't help with. I wonder if we can manipulate that setting via a plugin (so we can use our current permission under the old name to automatically add the new name to the list). Is that something you'd like explored, or has the decision been made to keep the old name forever?

jrfnl commented 1 year ago

I wonder if we can manipulate that setting via a plugin (so we can use our current permission under the old name to automatically add the new name to the list). Is that something you'd like explored?

Well, I'm pretty sure that it is technically feasible, we effectively do something like that in the test suite of this project.

Having said that, IMO, I don't think it is desirable to do this as it would effectively bypass and undermine this security feature Composer put in place, which I don't think is the right thing™ to do.

It would also create a lot of questions and possibly uproar when people would suddenly see their composer.json updated without them giving permission for this, let alone without them knowing about the package rename (yet), which has a high risk of damaging the reputation of this plugin as it could now be considered that the plugin poses a security risk (as it would adjust the allow-plugins permissions without asking for permission to do so).

Aside from the above, it would also require a new 0.7.x tag in which to do the manipulation and then would only be effective for those projects which would upgrade to that 0.7.x tag before upgrading to 1.0.0.

or has the decision been made to keep the old name forever?

The decision has not been made for definite yet, this should be a decision from all maintainers with input from the community, though I think it's pretty clear where I stand on it.

Potherca commented 1 year ago

This comes back to my original comment regarding meta-packages and wrapper repos.

The only possible solution for two packages is creating two repos: a renamed package repo which contains the actual code and the original named package repo with only a transparent PHP proxy class (which extends the code from the renamed package).

That would work by keeping the name, functionality and allow-plugins equal, so people can migrate to the new name.

The question is if that effort is worth the cost...

Potherca commented 1 year ago

To clarify what I mean, I've made an example implementation: 75705271784bf3ea1384c0409a14fb3ce39e4c5d (branch issues/159-rename-package-for-packagist)

The most relevant changes are src/Plugin.php and composer.json (as almost everything else is deleted).

jrfnl commented 1 year ago

That would work by keeping the name, functionality and allow-plugins equal, so people can migrate to the new name.

I wonder about the allow-plugins though,... wouldn't Composer ask permission for both packages which are marked as composer-plugin ? After all, the "new" package would also be installed and be registered as a Composer plugin...

Potherca commented 1 year ago

I wonder about the allow-plugins though...

We'll have to try (with a dummy) to see what actually happens, I think.

(Or try and see by reading the Composer codebase. Or both? :shrug: )

I'll see when I can make some time to try.

Potherca commented 1 year ago

I'm inclined to scrap this for v1, so we can get that out of the door.

Either we'll find a backward-compitable way to do this (and then the release version/date won't matter), bump it to v2, or indefinitely postpone it.

jrfnl commented 7 months ago

I'm inclined to close this issue as not feasible, nor desirable for end-users.

Potherca commented 6 months ago

Agree. :+1: Better things to focus on IMHO.

PHPCSStandards / composer-installer