Allow an easier renaming of packages

[stof]

I thought about the right way to rename a composer package without breaking everything for users.

replace is not the right feature for that:

• it does not work anymore since Composer improved the feature to avoid hacking packages through replacements, given that it requires an explicit requirement of the new package => forces users to change all their dependencies on your package, so not user-friendly renaming
• it does not work for existing releases (as they don't replace the old package name while Packagist will still rename them as it allows a single package name per VCS repo, not a name per branch)

I found a solution to make the replacement transparent for users: create a metapackage with the old name, which has a requirement on the new name, and then create all the releases you need to maintain BC for your users.
Currently, such setup requires creating a github repo (or a gist repo potentially) with just a composer.json file in it and then registering it on Packagist (after understanding the way this works). It might be easier to have Packagist generate such metapackage for us

[Seldaek]

I think adding a new package and using the Abandon feature to point people to the new name is working out quite well for those cases where it's really needed. Renaming is still ultimately a bad idea though so not sure if we really want to facilitate it.

[stof]

@Seldaek the latest discussion I know of abotu renaming a package is for the facebook sdk (because they have a crappy name as they included -v4 in it, which hurts them when bumping the version to 5.0).

The issue with abandonning the package and creating the new one is that Composer would consider them as separate packages, and it would then be possible to have old-name#old-release and new-name#other-old-release installed together while they should technically conflict (they contain different versions of the same classes).
I agree that renaming should be avoided ultimately, but unfortunately this is requested regularly

[Seldaek]

I see that yes but I hope with time this becomes less and less necessary as people learn the best practices and stop doing weird things like -v4 in the name :)

[jamiehannaford]

I'm in a similar position and would like to rename a package. I don't particularly want to abandon an already well-established project with its own community. I find that users are very wary of making a radical shift to a new project.

In terms of the reasons why, I wouldn't say it's necessarily tied to "best practices" -- projects will naturally evolve and sometimes that will need to be reflected in the package name. Renaming Github repos is extremely easy: they even redirect the old repo to the new one for you, including for clone, fetch and push. If composer/packagist could enable renaming and handle redirects, that would be fantastic.

[Seldaek]

@jamiehannaford the best canonical answer I have on how to rename is #47 (comment) - it might be possible to do something smarter on our end but that's work and I am not even sure what the best approach would be, I haven't seen a really good solution yet. So for now that's that sorry :)

[ryanwinchester]

I don't see why renaming is bad if there is a redirect. it seems to be working for github, bitbucket, etc...

things change, people move, packages are transferred ownerships, vendors change. these are not "new" packages and the old ones are not "abandoned", they've just moved. i.e. mv == rename

[ryanwinchester]

I see that yes but I hope with time this becomes less and less necessary as people learn the best practices and stop doing weird things like -v4 in the name :)

we don't live in an idealistic society where nobody makes decisions they don't regret or didn't think through to completion, we live in a world where people make mistakes and things change, it's better to be able to account for that and make them gracefully.

[Seldaek]

Yup, but the bottom line is renaming is possible via the abandonment of a given package, the only "problem" is you lose your download stats, but that's not exactly a huge deal IMO.

[jamiehannaford]

@Seldaek Well if you've worked really hard on a package, and due to the stats it's seen as the official library for an ecosystem, asking them to reset everything (due to technical constraints rather than best practice) is really inconvenient. Vanity metrics matter to some people, regardless of how many times one person says otherwise 😛

I also think conservative users who don't update their dependencies a lot will end up just sticking to the abandoned package - which is not great. Security vulnerabilities might be exposed, and the original project will end up having a fragmented userbase. Redirects would go a long way towards mitigating those problems.

[igorsantos07]

I'm on the same boat here... I'm the new maintainer of an old and still very active package for the Laravel community, but the old vendor name was bad and when the ownership was transferred, the name changed as well. However, it's very weird for the users to find the package under a vendor in Github and another vendor (the old one) in Packagist/Composer.

Besides that, the idea of abandoning the "old" package is bad, as said before: statistics and userbase should not be abandoned, as the package itself was not.

[petkopara]

Another one on the renaming boat. Besides the problem with the statistic, what about the place in the search engine result page.

Will my new package be on the same place, that was the abandoned package?

I think not giving chance to rename the current package is lack of functionality.
Bad idea is to not provide the functionality, that is common for github or bitbucket.

[drAlberT]

Another guy on the boat ..

[Wirone]

We need this too, but in our case it's package distributed through company's Satis. So @stof's solution ("It might be easier to have Packagist generate such metapackage for us") will not work for us since we don't want to add meta-package to Satis and Satis can't do anything automatically (I think so).

We have custom Silex app bootstrap package, which requires core package (in order to add fixes and new features to existing apps created with bootstrap). Bootstrap itself is not a problem, because each app is a clone from package and does not contain relation to it, so basically we can rename it safely. But every app created with bootstrap requires core package, which's name we would like to change too...

We could change it, then change requirements in those apps, but I don't know every app created with this bootstrap (package is available to whole company) so it would be safer if Composer could handle such rename and use new package name instead of old name automatically.