Movatterモバイル変換

[0]ホーム
URL:

Skip to content
Search Gists
Sign in Sign up

Instantly share code, notes, and snippets.

@mitchellh
Last activeJune 12, 2025 22:35
    • Star(28)You must be signed in to star a gist
    • Fork(2)You must be signed in to fork a gist
    Save mitchellh/90029601268e59a29e64e55bab1c5bdc to your computer and use it in GitHub Desktop.
    Archive List

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

    The reality of each of the projects listed below is thatI've almost completely ignored issues and pull requests fora couple years. Archiving the project is more about sendingthe right message about the status of the project more than anypractical impact since almost all haven't been maintainedrecently anyways. I'm sorry about not being transparent aboutthis earlier.

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

    To repeat: Existing dependent projects will continueto work. I only plan onarchiving the projects below,I'mnot deleting them. So existing projects that dependon these repositories will continue to function as before.And like I said, given I've poorly maintained them for acouple years already, there is already little practicaldifference in this decision (i.e. I've closed few if anyissues/PRs), I'm just trying to be more transparent andintentional moving forward.

    The List

    (All under "mitchellh" on GitHub)

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

    @mfridman
    Copy link

    Thanks for the transparency, this answers my question w.r.tmitchellh/protoc-gen-go-json#17 (comment).

    I presume you're not interested in adding collaborators/maintainers on the repositories themselves?

    Given this, I'll probably fork since it's very much in my current wheelhouse and a few users have been asking about this plugin.

    @mitchellh
    Copy link
    Author

    I presume you're not interested in adding collaborators/maintainers on the repositories themselves?

    I'd rather not, because I don't want to send the message under my namespace "mitchellh" that it's being maintained. I'd prefer the ownership be clear. If you're interested in taking this on, you've been consistent in contributing to this project in the past and I'd be happy to bless that direction!

    @bep
    Copy link

    bep commentedDec 20, 2023

    Ref. the "blessed fork" ofmapstructure

    @mfridman
    Copy link

    mfridman commentedDec 20, 2023•
    edited
    Loading

    I presume you're not interested in adding collaborators/maintainers on the repositories themselves?

    I'd rather not, because I don't want to send the message under my namespace "mitchellh" that it's being maintained.

    Makes perfect sense. There's a satisfying feeling of archiving a Github project and eliminating the overhead (which includes maintaining collaborators, etc.).

    Given I still use this plugin and it's fairly popular in the community, I'll fork it and go from there. (ps. our paths crossed a few times in Go projects, 'till next time in a different ecosystem 🌊)

    https://github.com/mfridman/protoc-gen-go-json

    @tuananh
    Copy link

    Ref. the "blessed fork" ofmapstructure

    * https://github.com/go-viper is a org with no (1?) member and only one project (mapstructure).* This is not the same as @spf13 's https://github.com/spf13/viper project (which I assume is the "well-maintained, well-known Go project" you refer to).

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

    @jamietanna
    Copy link

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

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

    @bep
    Copy link

    bep commentedDec 20, 2023

    @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.

    @mitchellh
    Copy link
    Author

    mitchellh commentedDec 20, 2023•
    edited
    Loading

    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 Iasked for clarification and will re-add that link once I receive it.

    EDIT: After theresponse and thecontribution 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.

    @sagikazarmark
    Copy link

    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.

    @dereknola
    Copy link

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

    The fun hell of go dependency chains:

    go: github.com/Microsoft/hcsshim@v0.11.4 requiresgithub.com/open-policy-agent/opa@v0.42.2 requiresoras.land/oras-go@v1.2.0 requiresgithub.com/distribution/distribution/v3@v3.0.0-20221208165359-362910506bc2 requiresgithub.com/mitchellh/osext@v0.0.0-20151018003038-5e2d6d41470f: 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 anissue with them to move to a much newer version of open-policy-agent

    @mitchellh
    Copy link
    Author

    mitchellh commentedDec 20, 2023•
    edited
    Loading

    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.

    @dereknola
    Copy link

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

    @cfabianski
    Copy link

    cfabianski commentedDec 21, 2023•
    edited
    Loading

    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 blessinggoreleaser/goreleaser#4493 (comment)

    @guettli
    Copy link

    Maybe it makes sense to create something likePython Jazzband?

    @thaJeztah
    Copy link

    thaJeztah commentedJan 9, 2024•
    edited
    Loading

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

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

    git checkout v0.11.4go mod graph| grep' github.com/distribution/distribution/v3'oras.land/oras-go@v1.2.0 github.com/distribution/distribution/v3@v3.0.0-20220526142353-ffbd94cbe269go mod graph| grep' oras.land/oras-go'github.com/open-policy-agent/opa@v0.42.2 oras.land/oras-go@v1.2.0go mod graph| grep' github.com/open-policy-agent/opa'github.com/Microsoft/hcsshim github.com/open-policy-agent/opa@v0.42.2

    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/distributiongo.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

    @zhulik
    Copy link

    zhulik commentedJul 29, 2024•
    edited
    Loading

    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

    @grongor
    Copy link

    👋 In case someone is looking for an alternative tohttps://github.com/mitchellh/panicwrap, I would like to recommend my libhttps://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.

    @bep
    Copy link

    bep commentedAug 15, 2024

    @Asuan
    Copy link

    @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

    @thaJeztah
    Copy link

    @Asuan perhaps worth considering contributing tohttps://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.

    @StevenACoffman
    Copy link

    I have found it quite helpful to usehttps://github.com/ldez/distributarepo (similar touseful-forks but as a CLI tool) to look up useful forks of these archived repositories.

    For instance, forgithub.com/mitchellh/go-ps
    You can use:

    distributarepo -o mitchellh -r go-ps

    And find the top few to look at:

    |                                FORK                                 |                                         AHEAD                                          | BEHIND | STARS | FORKS | ISSUES ||---------------------------------------------------------------------|----------------------------------------------------------------------------------------|--------|-------|-------|--------|| [arp242/ps](https://github.com/arp242/ps)                           | [8](https://github.com/mitchellh/go-ps/compare/master...arp242:ps:master)              |      0 |     0 |     0 |      0 || [jgbooks/go-ps](https://github.com/jgbooks/go-ps)                   | [8](https://github.com/mitchellh/go-ps/compare/master...jgbooks:go-ps:master)          |      0 |     0 |     0 |      0 || [goss-org/go-ps](https://github.com/goss-org/go-ps)                 | [7](https://github.com/mitchellh/go-ps/compare/master...goss-org:go-ps:master)         |      0 |     4 |     2 |      0 || [q84fh/go-ps](https://github.com/q84fh/go-ps)                       | [5](https://github.com/mitchellh/go-ps/compare/master...q84fh:go-ps:master)            |      0 |     0 |     0 |      0 || [habitualdev/go-ps](https://github.com/habitualdev/go-ps)           | [5](https://github.com/mitchellh/go-ps/compare/master...habitualdev:go-ps:master)      |      0 |     0 |     0 |      0 |

    @rasa
    Copy link

    A great functional (not drop-in) replacement for go-homedir ishttps://github.com/adrg/xdg

    @dolmen
    Copy link

    Most uses ofgo-homedir should instead be replaced byos.UserHomeDir(). Seemitchellh/go-homedir#34 (comment).

    Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment
    [8]ページ先頭
    ©2009-2025 Movatter.jp