Archive List

archive.md

Planned Repo Archive

In the new year, I plan on archiving the repositories below. Because I plan on only archiving the repositories, any project that depends on any of these projects will continue to work. However, I will no longer be accepting issues or pull requests and will never tag a new release.

The reality of each of the projects listed below is that I've almost completely ignored issues and pull requests for a couple years. Archiving the project is more about sending the right message about the status of the project more than any practical impact since almost all haven't been maintained recently anyways. I'm sorry about not being transparent about this earlier.

Admittedly, this is something I should've done long ago, but the reason why I am doing this now is a combination of multiple factors. One, all of the projects below are Go libraries, and I am now very rarely writing Go. Second, I am no longer actively working on any projects that consume these libraries, so my motivation to keep them up to date is gone. Third, I don't have the personal time to keep up with this many libraries anymore. And fourth, I'm trying to free up more obligations so I can healthily work on new things.

To repeat: Existing dependent projects will continue to work. I only plan on archiving the projects below, I'm not deleting them. So existing projects that depend on these repositories will continue to function as before. And like I said, given I've poorly maintained them for a couple years already, there is already little practical difference in this decision (i.e. I've closed few if any issues/PRs), I'm just trying to be more transparent and intentional moving forward.

The List

(All under "mitchellh" on GitHub)

• cli (blessed fork: https://github.com/hashicorp/cli)
• colorstring
• copystructure
• go-homedir
• go-mruby
• go-ps
• go-server-timing
• go-vnc
• hashstructure
• ioprogress
• mapstructure (blessed fork: https://github.com/go-viper/mapstructure)
• panicwrap
• pointerstructure
• protoc-gen-go-json (blessed fork: https://github.com/mfridman/protoc-gen-go-json)
• reflectwalk

If you're interested in continuing any of these projects, please fork the project. If you're an active user of one of these projects and have a history I can point to to build trust, I'd be happy to mark your fork as blessed.

Not in the list but Gon could maybe be included? http://github.com/Bearer/gon
Bearer/gon#7

[EDIT] Goreleaser's maintainer will be waiting for the blessing goreleaser/goreleaser#4493 (comment)

Maybe it makes sense to create something like Python Jazzband?

@dereknola I'm a bit confused where that dependency comes from in your example; looking at hcsshim v0.11.4, there's no dependency on https://github.com/distribution/distribution/v3 (only on github.com/docker/distribution v2.8.1+incompatible); https://github.com/microsoft/hcsshim/blob/v0.11.4/go.mod#L50C14-L50C20

• "old" docker/distribution (which isn't a go module) doesn't have it in vendor; https://github.com/distribution/distribution/tree/v2.8.1/vendor/github.com (and doesn't have it in vendor.conf; https://github.com/distribution/distribution/blob/v2.8.1/vendor.conf#L25)
• current main branch doesn't have it; only "mapstructure" https://github.com/distribution/distribution/blob/1d2895f2bfee0071d1da65c75ed239cc952d20d5/go.mod#L23
• but the commit in that log indeed had it, but that's some old version from the main branch (not a released version) distribution/distribution@362910506bc2 (indirect dependency: https://github.com/distribution/distribution/blob/362910506bc213e9bfc3e3e8999e0cfc757d34ba/go.mod#L61). I wonder why go modules would even try that version (given that it's not referenced in hcsshim)

Ah, I guess it finds some transitive path in oras; when trying the hcsshim repository;

git checkout v0.11.4

go mod graph | grep ' github.com/distribution/distribution/v3'
oras.land/[email protected] github.com/distribution/distribution/[email protected]

go mod graph | grep ' oras.land/oras-go'
github.com/open-policy-agent/[email protected] oras.land/[email protected]

go mod graph | grep ' github.com/open-policy-agent/opa'
github.com/Microsoft/hcsshim github.com/open-policy-agent/[email protected]

oras v1.2.0 indeed depends on distribution/distribution (but some other commit (ffbd94cbe269)); https://github.com/oras-project/oras-go/blob/v1.2.0/go.mod#L7

But not sure why it would look at that, given that the repository already has depencencies resolved (which doesn't include that version);

git grep distribution/distribution
go.sum:github.com/distribution/distribution/v3 v3.0.0-20220526142353-ffbd94cbe269/go.mod h1:28YO/VJk9/64+sTGNuYaBjWxrXTPrj0C0XmgTIOjxX4=
test/go.sum:github.com/distribution/distribution/v3 v3.0.0-20220526142353-ffbd94cbe269/go.mod h1:28YO/VJk9/64+sTGNuYaBjWxrXTPrj0C0XmgTIOjxX4=
vendor/github.com/google/go-containerregistry/pkg/v1/remote/transport/error.go: // https://github.com/distribution/distribution/blob/6a977a5a754baa213041443f841705888107362a/registry/api/errcode/register.go#L60

If someone is looking for an alive fork of go-mruby: https://github.com/zhulik/gruby. it's still WIP, but it already works with mruby 3.3 and go 1.22

👋 In case someone is looking for an alternative to https://github.com/mitchellh/panicwrap, I would like to recommend my lib https://github.com/grongor/panicwatch. It's not a fork but it does the same job via a different approach. I don't plan on adding any new features, but I'll look into any issues that may arise :) It's used in dozens production apps at @cdn77 and it serves us well.

hashstructure: https://github.com/gohugoio/hashstructure

@mitchellh at begin many thanks for you work.

I a little improved hashstructure and try to keep backward compatibility

https://github.com/Asuan/hashstructure

• added support of fields like int/uintXX (int8)
• improved hashing performance ~30%
• fixed panics with chan func fields

@Asuan perhaps worth considering contributing to https://github.com/gohugoio/hashstructure, which was created earlier and is part of the "hugo" org, which is fairly well-known, so would likely be preferred by other projects as a trusted upstream to use.