Allow users to delete new packages #166
Comments
|
Why not delete automatically those packages with invalid source repositories, maybe after a grace period of a few days/weeks to cover cases of technical problems with these repositories? |
|
@frosas how do you detect an "invalid source repository" ? Most of such packages are people adding their fork on packagist to test the composer.json they are adding instead of using a VCS repository in their composer.json. So the source url is valid, but it is not the appropriate one. |
|
@stof I should have supposed it wouldn't be that easy. Then why not simply allow users to delete any of their packages? |
|
@frosas because once a package is used by someone, deleting it from Packagist breaks the projects relying on it. Imagine what would happen if |
|
@frosas I had to explain this reason to several people already. And most of these people simply did not think they would break the code of other people by removing a package from Packagist or renaming it. So I don't think adding a button allowing to remove any package is wise right now. |
|
@stof sincerely I wouldn't use a package of someone not understanding this, "make it stupid proof and only stupids will use it" |
|
@frosas the issue is that you cannot really know if the guy understands it until your app explodes because he removed the package... |
|
Now I see rubygems doesn't allow deleting gems either (you still can ask them to remove your gem if you pushed sensitive data for example). Probably removing packages is more sensible than I expected to situations where one is not aware of the actual dependencies. |
|
What if "deleting" a package just removed it from the vendors public list but it still existed, this would help keep the package from being publicized to new users without breaking backwards compatibility. You could create a UI section to show "deprecated" packages for those projects that still required them. Perhaps composer could also include a deprecated rule with a message. This way if you "remove" your package and leave a message to be displayed if someone tries to load it. Something like: {
"deprecated": {
"message": "This package has been deprecated",
"recommend": "vendor/package"
}
} |
|
Since my other ticket got closed as a duplicate, I thought I'd chime in here: As a package author, I find the idea that I can never undo publication of a package absolutely horrible and I will really think twice before clicking the Submit button again. This is partially because due to some packagist strangeness one of my packages is listed twice there with different names now, which will confuse users for all eternity if you guys have your way. I also find that disallowing package removal because it might break installations a bit beside the point. As the package maintainer, I can always break all installations, e.g. by just deleting the github repo or by replacing all code in the repo with an rm -rf command and declaring that a minor stable release. AFAICT, all that is accomplished by not allowing package deletion is that packagist.org will slowly fill up with lots of broken dummy or test entries, because new users tend to make mistakes. |
|
All of those things have already been addressed. The way to delete a package that is widely used is to contact us to remove it. So we can make sure migration for users works well. And the whole point of this ticket is that packages with few users or new ones should be deletable by the admin themselves which would entirely take care of any dummy/test entries. So I'm not sure what you are so upset about. |
|
Oops, wrong button, sorry about that. |
|
So... to delete a package what is the procedure? do I open a ticket on github, do I write you an email, is there a standardized form available somewhere? Are there procdures to establish validity of delete requests? Can they be denied for some reason? I mean, if you guys want to put up with manually removing packages for all eternity, go for it. To me, that just sounds like a scheme that is bound to fail because eventually the packagist mainainers will become tired of it, they will make mistakes that upset the community and so on and so forth. I guess I'm upset because it feels like you pulled a Facebook on me. I click this Submit button once because people (in fact, only on person...) asked me about setting something up on packagist. It's only later that I learn that all my package are belong to you now (please note the slight irony here), in the sense that I may put it on your site, but then it's out of my hands, and I have to resort to asking some unknown (to me) admins if they are in the mood to remove it. So the non-flamebait summary:
|
|
@flack 99% of services ? See above. Rubygems does not allow deleting either. And to remove a package, either opening an issue on asking on the IRC channel works. |
|
@stof OK, you found one counter example, and there may be more. But I meant "services" in a bit more general sense: If I put something on some site, I have the expectation that I can remove it again. I mean, even Facebook allows you to "delete" stuff. I can delete repos on github, remove apps from app stores and so on and so forth. I know that you will now say something like "the Internet never forgets", but let's not get philosophical here: The point is that not providing a delete feature achieves next to nothing as far as protecting existing installations is concerned. IMHO it also sends the wrong message to package maintainers, who should be in control of their distribution channels (of course, open source packages can still be forked and distributed in a different way by someone else, but that is also beside the point) |
|
I am also vote for the deleting package capability. It is must have feature. It is inconvenient to have broken links in the developer account. |
|
I understand the concern for deleting packages that many sources may be relying on - i get that. I dont want to break someone elses code by deleting a package. But I think it's foolish to be (essentially) forced to maintain a package forever because there is no way to remove it from the public eye. I think leaving ancient packages available to the world just because the vendor has no control over their distribution is potentially as damaging as removing them out from under someone. An archive feature, if not a delete feature. This ensures no new developers use an outdated project just because it's forced to remain public by your service but anyone that has a project that depends on the package doesn't lose it. I also chuckle when thinking about this discussion because a member of the Packagist administration deleted one of my packages out from under me without any discussion, just because the proper vendor finally released a version for composer.
No harm done, it was resolved quickly. |
|
hi, the big issue IMHO is than when your searching for "term" you'll have "term" and theses forks (as said @stof). We may just have to be able "deactivate" a repository on packagist, it'll not appear on packagist but we'll not broke links. I guess reactivate a repository can be great too :) |
|
Hi, I absolutely second the plea for the Delete function. I haven't found any other reason for not allowing this functionality here in this discussion than protecting projects dependent on packages managed by Packagist. Well, if this is the only argument, the stance not to allow Deletions is completely moot since a developer having full control over the package source has many other ways at his disposal how to sabotage the package users. As Packagist is but a vehicle helping to get packages from their author to a user, it really won't save the world from developers gone gone evil or mad (or just careless). By not allowing deletions it will just generate more junk and debris. And the potential damage caused by all that clutter is IMHO much worse than the few incidents where a package registration might be deleted inappropriately. If such an inappropriate deletion was just a mistake, the developer will surely register his/her package again ASAP. If it was an intention to harm the users, the villain will easily find other ways even if Packagist would not allow the deletion. Besides there are other ways to prevent the accidental deletions (from a simple password field on the delete form, over a dedicated package password generated at its registration, or a simple e-mail confirmation, or finally up to two-step verfication and QR code scanning by your smart phone form the screen.) Someone said 'imagine what would happen if symfony/symfony ceased to exist on Packagist' as an argument for not allowing deletions. I am just new to Packagist, but as I see it, it would not break anything for current Symfony users, would it? They just would not be able to update, right? Their apps would continue to work as they used to using the old Symfony version. With all due respect I think that it simply is none of Packagist's business to police the package authors. The About page says: 'Packagist is a Composer package repository. It lets you find packages and lets Composer know where to get the code from.' Not a word about user procection or whatever. There are numerous examples where 'empowering' people with responsibility and giving up control in favour of the wider public have proved extremely successful (there is a limit though, of course). Take public wikis for example. Hey, anyone can go and delete... But it just does not happen much. Guys (the Packagist authors), if you really really think the Delete non-existence is what the Packagist is and should be about, please at least formalize the package removal somehow (e.g. a removal form). In the meantime, please remove my packages: dluphpsettings/dluphpsettings They are only wrongly namespaced copies of the remaining packages under my profile. No one is linking them, I am pretty sure. (I hate to see this junk on my profile.) Packagist is a great service but by not letting responsible people fully control their work it just shoots itself in the foot. Instead of preventing package authors to delete their package registrations, we should think about hard/soft deletions, what happens to the names of packages which were deleted, etc. |
|
@dlu-gs I deleted your dupe packages. |
|
I'll chime in +1 for delete. The projects I've been working on are very modular and constantly undergoing refactoring. I've also been learning a lot along the way. All that means I've generated some trash on packagist. I'd like to clean it up. But I can't. Here's a list of packages that need to go: superdweebie/SdsDoctrineExtensionsModule If packagist is not going to budge on no-delete, then could we have a sandpit version of packagist with delete? Ie, heavy alpha style development work happens through the sandpit, and can be deleted if it is junk. I know it's possible to set up your own personal package repository, but that's hardly a good route for new users because it is a significantly steeper learning curve. |
|
@superdweebie thanks for the list, I deleted all of those. And we are going to allow deletion as this issue states, but the work needs to be done. |
|
@Seldaek thanks for the cleanup. And great that delete is coming. I understand the work needs to be done :) |
|
Just to throw my 2-cents in here: I don't think that people should be able to arbitrarily delete packages, except in certain situations. Those situations being either zero installs or the package never went beyond a "package development version" (e.g. never was tagged as an official version). I also like @joseym's "deprecated" rule suggestion. |
|
@dhorrigan keep in mind that until packagist stores its own archives for the tagged releases, a user can still break everything even if packagist does not provide a delete button as github provides one. |
|
@stof I understand that, but I would like to hope that most developers can be "trusted" not to intentionally break it. |
|
@dhorrigan if you consider they can be trusted, you could add the delete button and trust them not to break packagist intentionally either :) |
|
Ok done. If it has <50 installs you can delete it, if not ask. I think under 50 installs we can safely assume it's still personal tests or a few early users but no massive amount of people will be pissed off by a deletion. |
|
Hey @Seldaek, Where do I ask for a package to be deleted? This one got heavy testing, and therefore got to 98 downloads, but its moved to a new location. Can you please kill it off for me? https://packagist.org/packages/mrphp/yii-dressing Thanks. |
|
@cornernote done, thanks for letting me know. |
|
Please delete the following package: https://packagist.org/packages/checkdomain/upload-manager-bundle |
|
@KoernerWS done |
|
@Seldaek, please delete https://packagist.org/packages/cakephp/apple_touch - namespace fix. |
|
Done |
|
I've decided to restructure my packages before releasing first version. So I deleted the packages. Unfortunately the packages are still found if I use the repository search (if I use the only name option only). Can you please have a look and delete following repositories: contao-bootstrap/bundle-all |
|
@Seldaek |
|
Done
|
|
Hello @Seldaek, thank you, we found that https://packagist.org/packages/magento/product-community-edition is deleted and not available on web interface. May you refresh packages.json or suggest how to fix it? |
|
Is it really a big problem that it still is in the json data? I can
flush it from there but that takes quite a while as right now we don't
handle deletions very well, and I'd rather not do that for nothing.
|
|
Hi @Seldaek, yes it is really big issue. |
|
But if you define your own custom repository it should take that package
instead of loading it from packagist, so I don't really see how that's a
problem, anyway I'll run a cleanup tomorrow morning.
|
|
@Seldaek, there is few issues actually.
|
|
Hello @Seldaek, have you any updates or suggestions? |
|
Ok it should be removed now, sorry for the delay
|
|
@Seldaek, thank you, appreciate it. |
|
Please delete the following package: |
|
Done
|
|
Please delete this package: |
|
Done, in the future though please reach out to [email protected] to request package deletions to avoid spamming everyone in here. I'll lock this issue now. |
We should allow users to delete new packages (recently created & few installs) so that mistakenly added packages can be removed without danger of projects depending on them already.
The text was updated successfully, but these errors were encountered: