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.

i made the mistake assuming it's related to https://github.com/spf13/viper too

+1 on the fact that it does seem a little confusing - but as per mitchellh/mapstructure#349 (comment) this appears to be intended. The author is a regular committer to viper and it looks like it is a reasonable request + move

@jamietanna I'm also a long time committer to Viper, and I have not seen a discussion about moving the repo into an org (I did a search now). This is in the end all fine and dandy, I'm sure, but the "blessed fork" labels should be not added without any inspection; I was about to blindly do a "search and replace" of the mapstructure imports based on the above premise.

I removed that link for now. I’ll do a bit more diligence on that and then readd later if it makes sense. I'm pretty sure that's where the Viper projects are going to be transferred to eventually and the maintainer is the also the maintainer of Viper, but I asked for clarification and will re-add that link once I receive it.

EDIT: After the response and the contribution history, I believe the mapstructure fork has enough background for me to call it trusted. I don't know the maintainer personally but there's enough social evidence for me to trust the intentions.

I've been the sole active maintainer of Viper for some years now.

Viper itself will not move, but some of the components will be extracted to external repos. Instead of creating those repos under spf13 they will be moved under the go-viper organization.

I started documenting these decisions here: https://github.com/spf13/viper/pull/1171/files#diff-b7f53412bda09913026d36de226a3b27ea70c5dd598889cab3a5800c880a17a9

Hope that clarifies things a bit.

@bep both Steve and I are members of that organization. I know you are a committer in Viper, so I'm happy to add you there as well.

Also, I'm happy to invite individual contributors to the fork who are willing to help with maintenance.

I'm seeing that github.com/mitchellh/osext repo has been deleted. Unfortunately, this repo is still in active use across several large repos, most notably github.com/Microsoft/hcsshim. Is it possible to restore and archive that repo?

The fun hell of go dependency chains:

go: github.com/Microsoft/[email protected] requires
	github.com/open-policy-agent/[email protected] requires
	oras.land/[email protected] requires
	github.com/distribution/distribution/[email protected] requires
	github.com/mitchellh/[email protected]: invalid version: git ls-remote -q origin in /home/derek/go/pkg/mod/cache/vcs/94ed57c5b21c953d93b47487113db43a5c9b69fd990329ec70dc77348c4dd443: exit status 128:
	remote: Repository not found.
	fatal: repository 'https://github.com/mitchellh/osext/' not found

For what its worth, I have opened an issue with them to move to a much newer version of open-policy-agent

I'm seeing that github.com/mitchellh/osext repo has been deleted. Is it possible to restore and archive that repo?

No, sorry. I don’t have access to the source code at all anymore. Even if I did, that repository had a bolded warning in the readme for around 6 years or something like that asking people to not use the project and move on to using the Go stdlib or some other option (the functionality most was moved into the Go stdlib). I think 6 years is long enough to warn users. Sorry about that.

Hey no problem, I understand people ignoring warning about deprecation.

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.