core/corenet: Remove this unused package

[wking]

It was renamed from core/net.go in d8d933c (move core/net.go to
'corenet' and change interface a tad, 2015-02-14), but no consumer
imports were updated in that commit. I've searched the Git history
looking for the previous consumers, but [.]Dial[(] and [.]Listen[(]
match a lot of stuff ;). GoDoc doesn't list any consumers (either
inside or outside this repository 1.

[whyrusleeping]

nope. this one is not unused. I have a bunch of different programs that import ipfs as a library and use this.

[whyrusleeping]

including this: #1089

[wking]

On Sat, May 02, 2015 at 12:03:39PM -0700, Jeromy Johnson wrote:

nope. this one is not unused. I have a bunch of different programs
that import ipfs as a library and use this.

Good to know. You should probably search for those projects on GoDoc,
so they show up in its dependency listing 1.

[jbenet]

You should probably search for those projects on GoDoc, so they show up in its dependency listing

GoDoc only lists a minority of dependencies. Many packages will never be released in the open and thus will never show up as dependencies. we cannot make assumptions like "nobody is importing this because godos/sourcegraph/etc don't show anything".

[wking]

On Sat, May 02, 2015 at 01:18:03PM -0700, Juan Batiz-Benet wrote:

You should probably search for those projects on GoDoc, so they
show up in its dependency listing

GoDoc only lists a minority of dependencies. Many packages will
never be released in the open and thus will never show up as
dependencies. we cannot make assumptions like "nobody is importing
this because godos/sourcegraph/etc don't show anything".

#1089 landing will restore local consumers (still missing docs and
tests…), so folks in IPFS will know why the library is useful. But I
think we need a motivating consumer like that to demonstrate that
API is worth the cost of maintaining it. That doesn't mean we should
run around pulling rugs out from under consumers, and this PR should
have had a deprecation note like 0ca7e7a (core/coreunix/add: Deprecate
Add, 2015-04-28, #1136) following the procedure in #1159. But if the
only consumers are quiet folks with closed-source packages, then I
think one of them should step up and at least explain how the library
is useful before the deprecation kicks over into removal. If I was a
downstream consumer, I'd rather have upstream acknowledge that they
were no longer maintaining a library (by deprecating and removing it)
than to have them leave it quietly lingering around on life support
without docs, tests, or internal consumers (which I might not notice
until I get bitten by a bit-rotted bug :p).