[arch-general] godep has been deprecated in favor of dep
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)
On 02/24/2018 09:18 PM, Adam Levy via arch-general wrote:
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/
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.)
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
On February 25, 2018 2:51 AM, Eli Schwartz via arch-general <arch-general@archlinux.org> wrote:
On 02/24/2018 09:18 PM, Adam Levy via arch-general wrote:
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:
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.)
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
On 2018-02-25 12:41, Jordan Glover via arch-general wrote:
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
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 < arch-general@archlinux.org> wrote:
I guess Adam request should be sent to package mantainer instead of
On 2018-02-25 12:41, Jordan Glover via arch-general wrote: 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
On 02/25/2018 07:42 AM, Adam Levy via arch-general wrote:
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
On Sun, Feb 25, 2018 at 09:07:34AM -0500, Eli Schwartz via arch-general wrote:
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
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
participants (5)
-
Adam Levy
-
Bartłomiej Piotrowski
-
Eli Schwartz
-
Jordan Glover
-
Morten Linderud