Be able to remove haxelib project

[markknol]

By accident I added this lib http://lib.haxe.org/p/Bar but I really want it to be removed. How can this be done?

[wighawag]

this would indeed be useful to be able to remove things

[jgranick]

I would like to do this, or at least be able to flag a library as deprecated/renamed

[nadako]

I think I could implement that, but what's the official position on adding stuff to haxelib? I saw some PRs where @jasononeil and @back2dos were talking about about reworking the architecture before adding new commands, but it's 2015 now and we're still sitting on the same codebase. I'd say, let's just add missing things in the current arch and think about rewriting the whole thing later, when someone comes up who is willing to take the job.

[back2dos]

There are no official positions in this project I'm afraid. Mine is that removing should not be allowed, only hiding from search, etc. Also, the client code is quite a mess as it is, I prefer adding as little as possible. The necessity for this feature arises every two months or so. Generally I have handled this by hand. I don't know how well the site is moving along, but this kind of administrative stuff should go there.

On Sun, Mar 8, 2015 at 1:43 PM, Dan Korostelev notifications@github.com wrote:

I think I could implement that, but what's the official position on adding stuff to haxelib? I saw some PRs where @jasononeil https://github.com/jasononeil and @back2dos https://github.com/back2dos were talking about about reworking the architecture before adding new commands, but it's 2015 now and we're still sitting on the same codebase. I'd say, let's just add missing things in the current arch and think about rewriting the whole thing later, when someone comes up who is willing to take the job.

— Reply to this email directly or view it on GitHub https://github.com/HaxeFoundation/haxelib/issues/168#issuecomment-77746786 .

[jasononeil]

At the moment I've focused on the site providing a better experience for discovering and learning about projects.

I do intend to add some project management features though. I was mostly thinking about password resets, but deprecating projects is probably important too. I agree it's probably easier to manage through the web interface than yet another command on the haxelib client.

On Mon, Mar 9, 2015 at 4:26 AM, Juraj Kirchheim notifications@github.com wrote:

There are no official positions in this project I'm afraid. Mine is that removing should not be allowed, only hiding from search, etc. Also, the client code is quite a mess as it is, I prefer adding as little as possible. The necessity for this feature arises every two months or so. Generally I have handled this by hand. I don't know how well the site is moving along, but this kind of administrative stuff should go there.

On Sun, Mar 8, 2015 at 1:43 PM, Dan Korostelev notifications@github.com wrote:

I think I could implement that, but what's the official position on adding stuff to haxelib? I saw some PRs where @jasononeil https://github.com/jasononeil and @back2dos https://github.com/back2dos were talking about about reworking the architecture before adding new commands, but it's 2015 now and we're still sitting on the same codebase. I'd say, let's just add missing things in the current arch and think about rewriting the whole thing later, when someone comes up who is willing to take the job.

— Reply to this email directly or view it on GitHub < https://github.com/HaxeFoundation/haxelib/issues/168#issuecomment-77746786

.

— Reply to this email directly or view it on GitHub https://github.com/HaxeFoundation/haxelib/issues/168#issuecomment-77772161 .

[andyli]

I agree in general a project should not be removable, since it could break projects which already depend on it. Deprecating the project by submitting a new release with deprecation note with a "deprecated" tag should be good enough.

Exceptional cases, like those are pure mistakes and we've high confidence that no one depends on them, can be removed by request. So, yeah, I've just removed the "Bar" lib.

I'm keeping this open until we document the deprecation/removal process.

[kevinresol]

I think the developer has the "right" to remove a library he wrote, even it is depended on by other users? And I think it is really the lib developer's responsibility to communicate with its user about the removal.

[back2dos]

I don't think so. All code published on haxelib is published under a free license, whereby the author relinquishes any kind of ownership from which such a right might stem. The author can't tell you to uninstall the library locally. In fact even if the author had the technical means to remove the code from haxelib, they can't stop you from submitting it yourself.

Since we have no obligation to allow authors to remove code from haxelib, I think we can use that to provide a more reliable eco system (than for example NPM, where hell can break lose because one guy doesn't get to be the princess).

Haxelib should be basically insert only and we should follow that through by disallowing to modify existing versions.

[Gama11]

by disallowing to modify existing versions

Strongly in favor of that. Being able to re-release the same version again is a recipe for disaster (because then you can't actually tell what version of the version you have...).

[RealyUniqueName]

So, the conclusion is: don't allow users to remove projects from haxelib. For deprecation feature see #312

[Aurel300]

Maybe we can do something simple to prevent accidental submissions? A big fat, red warning text saying that a library cannot be deleted once added? Make the user type the full name of the library to confirm?

[RealyUniqueName]

Yeah, something like confirmation prompt should decrease accidents rate.