Discussion:
godep has been deprecated in favor of dep
(too old to reply)
Adam Levy via arch-general
2018-02-25 02:18:02 UTC
Permalink
Hello

Today I noticed that as of about 30ish days ago godep (
github.com/tools/godep) has been archived and is no longer supported. The
go dev team recommends using dep (github.com/golang/dep) instead.

As Arch strives to be as up to date as possible I suggest removing godep
from the official repos and potentially moving dep into the official repos
from the AUR. The AUR dep package appears to be well maintained.

Relevant links:
https://github.com/tools/godep
https://github.com/golang/dep
https://aur.archlinux.org/packages/dep/

Thanks!
Adam Levy (alaskanarcher)
Eli Schwartz via arch-general
2018-02-25 02:51:56 UTC
Permalink
Post by Adam Levy via arch-general
Hello
Today I noticed that as of about 30ish days ago godep (
github.com/tools/godep) has been archived and is no longer supported. The
go dev team recommends using dep (github.com/golang/dep) instead.
As Arch strives to be as up to date as possible I suggest removing godep
from the official repos and potentially moving dep into the official repos
from the AUR. The AUR dep package appears to be well maintained.
https://github.com/tools/godep
https://github.com/golang/dep
https://aur.archlinux.org/packages/dep/
So because it has been dropped 30 days ago, we should delete it from our
repos without first checking to see, I dunno, whether any other packages
in the repos depend on it? No thanks.

Nothing is stopping us from shipping *both* packages. For that matter,
nothing is stopping us from shipping *neither*...

Arch does not ship golang ecosystem tools because we have some sort of
fundamental goal to ship golang. We don't ship golang *itself* because
we have some fundamental goal to ship golang.

We ship it because Arch developers either use/want it, or use/want
software that depends on it. Happily, that goal coincides with the
ability to support popular programming languages... but do you think we
would force someone who doesn't like golang, to maintain the thing just
so we can have it in the repos? No, at best we would (try to) look to
sponsor a TU who cares.

By the same extension we won't blacklist software that is currently
maintained by a TU, that people use, that at least one package in the
repos has a makedepends on, just because the upstream developers have
decided that the software can and should be replaced by a newer, better
tool. Currently it is a violation of the Arch packaging rules to delete
godep even if we want to...
(That being said, terraform probably shouldn't makedepend on it, and
I've pointed that out to the maintainer.)
Post by Adam Levy via arch-general
As Arch strives to be as up to date as possible
We achieve that goal by providing the latest version of godep, thereby
ensuring that godep is up to date.

Determining which is the best tool to use is a choice for upstream projects.

Quite frankly we have more than enough ancient software that is
legitimately at the latest version a dead upstream provides, to rebut
your argument. Just because software is old, or not recommended by its
own devs, does not mean it isn't useful.
--
Eli Schwartz
Bug Wrangler and Trusted User
Jordan Glover via arch-general
2018-02-25 11:41:01 UTC
Permalink
Post by Eli Schwartz via arch-general
Post by Adam Levy via arch-general
Hello
Today I noticed that as of about 30ish days ago godep (
github.com/tools/godep) has been archived and is no longer supported. The
go dev team recommends using dep (github.com/golang/dep) instead.
As Arch strives to be as up to date as possible I suggest removing godep
from the official repos and potentially moving dep into the official repos
from the AUR. The AUR dep package appears to be well maintained.
https://github.com/tools/godep
https://github.com/golang/dep
https://aur.archlinux.org/packages/dep/
So because it has been dropped 30 days ago, we should delete it from our
repos without first checking to see, I dunno, whether any other packages
in the repos depend on it? No thanks.
Nothing is stopping us from shipping both packages. For that matter,
nothing is stopping us from shipping neither...
Arch does not ship golang ecosystem tools because we have some sort of
fundamental goal to ship golang. We don't ship golang itself because
we have some fundamental goal to ship golang.
We ship it because Arch developers either use/want it, or use/want
software that depends on it. Happily, that goal coincides with the
ability to support popular programming languages... but do you think we
would force someone who doesn't like golang, to maintain the thing just
so we can have it in the repos? No, at best we would (try to) look to
sponsor a TU who cares.
By the same extension we won't blacklist software that is currently
maintained by a TU, that people use, that at least one package in the
repos has a makedepends on, just because the upstream developers have
decided that the software can and should be replaced by a newer, better
tool. Currently it is a violation of the Arch packaging rules to delete
godep even if we want to...
(That being said, terraform probably shouldn't makedepend on it, and
I've pointed that out to the maintainer.)
Post by Adam Levy via arch-general
As Arch strives to be as up to date as possible
We achieve that goal by providing the latest version of godep, thereby
ensuring that godep is up to date.
Determining which is the best tool to use is a choice for upstream projects.
Quite frankly we have more than enough ancient software that is
legitimately at the latest version a dead upstream provides, to rebut
your argument. Just because software is old, or not recommended by its
own devs, does not mean it isn't useful.
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Eli Schwartz
Bug Wrangler and Trusted User
I guess Adam request should be sent to package mantainer instead of public
list but other than that it's legit and I don't see the point of public rant about
it. It doesn't help anyone.

​Jordan
Bartłomiej Piotrowski via arch-general
2018-02-25 12:23:33 UTC
Permalink
Post by Jordan Glover via arch-general
I guess Adam request should be sent to package mantainer instead of public
list but other than that it's legit and I don't see the point of public rant about
it. It doesn't help anyone.
I agree it was unnecessary. The bottom line, however, remains the same:
as long as it's required by other packages, it stays in the official
repositories. Even when it becomes a leaf package, it's up to the
maintainer to drop it.

Bartłomiej
Adam Levy via arch-general
2018-02-25 12:42:58 UTC
Permalink
I wrote Eli directly thanking him for the information as I had the mailing
list digest enabled earlier and so didn't have the thread to respond to.

I admit I was a little taken aback by the tone of Eli's response at first
but I hear and understand the message and I appreciate the explanation of
the rationale. I see that once a package is in the official report,
removing it is not a trivial matter and very rarely would be the right
course of action. Also I get that adding a package requires a TU to adopt
and maintain it.

I've been a daily arch user for over a year and I'm just starting to become
active in the community. Thanks for everyone's patience as I get up to
speed on the proper communication channels and policies.

On Sun, Feb 25, 2018, 3:23 AM Bartłomiej Piotrowski via arch-general <
Post by Jordan Glover via arch-general
Post by Jordan Glover via arch-general
I guess Adam request should be sent to package mantainer instead of
public
Post by Jordan Glover via arch-general
list but other than that it's legit and I don't see the point of public
rant about
Post by Jordan Glover via arch-general
it. It doesn't help anyone.
as long as it's required by other packages, it stays in the official
repositories. Even when it becomes a leaf package, it's up to the
maintainer to drop it.
Bartłomiej
Eli Schwartz via arch-general
2018-02-25 14:07:34 UTC
Permalink
Post by Adam Levy via arch-general
I wrote Eli directly thanking him for the information as I had the mailing
list digest enabled earlier and so didn't have the thread to respond to.
I admit I was a little taken aback by the tone of Eli's response at first
but I hear and understand the message and I appreciate the explanation of
the rationale. I see that once a package is in the official report,
removing it is not a trivial matter and very rarely would be the right
course of action. Also I get that adding a package requires a TU to adopt
and maintain it.
I've been a daily arch user for over a year and I'm just starting to become
active in the community. Thanks for everyone's patience as I get up to
speed on the proper communication channels and policies.
Sorry if I came across as too harsh. :o

FWIW I think I convinced someone to adopt dep in [community] as
independent from the existence of godep it would be nice to have
valuable ecosystem tools like this.

The godep maintainer will probably want to revisit whether it is worth
maintaining this after evaluating its continued (legacy) use in the
golang ecosystem.

We seem to have a fair number of AUR packages that still require it, so
this may be complicated.
--
Eli Schwartz
Bug Wrangler and Trusted User
Morten Linderud via arch-general
2018-02-25 14:18:25 UTC
Permalink
Post by Eli Schwartz via arch-general
FWIW I think I convinced someone to adopt dep in [community] as
independent from the existence of godep it would be nice to have
valuable ecosystem tools like this.
*Approaches golang packaging with a bottle of whisky, a stick and a whip*
--
Morten Linderud

PGP: 9C02FF419FECBE16
Morten Linderud via arch-general
2018-03-11 20:38:45 UTC
Permalink
Yo!

Just as a conclusive mail and some brief information!

dep has been added to community. I was initially unsure as the plans for dep was
to be merged upstream to essentially become "go dep" at some point in time. The
roadmap stated that the next release, 1.11, would have been this window. That
was apparently a lie for reasons unclear.

Meanwhile vgo was released on the 20th of February as a dependency management
tool, and has already been merged into go and will be included in the 1.11
realease, for reasons unclear. However after some more reading dep will continue
be the recommended tool for dependency management as both godep and glide has
ceased to be developed. Thus I found it useful to be in community.

TL;DR: Go still has issues they should have solved 9 years ago.

https://research.swtch.com/vgo-intro
https://sdboyer.io/blog/vgo-and-dep/
--
Morten Linderud

PGP: 9C02FF419FECBE16
Loading...