Question about the community and abandoned packages

<p>Hello!</p> <p>I am fairly new to GoLang and the ecosystem in general, because so far I&#39;ve been doing things the Go-way by only relying on my code and built-in packages, however I wanted to bridge the overhead by using a few community packages, like the awesome Gin HTTP framework.</p> <p>I ran into the issue of it replying on the package go-yaml/yaml.v2, which seems to be abandoned by its developers and many of issues / feature requests have gone unnoticed. So far I&#39;ve patched an issue locally where it incorrectly errors on a nil pointer on data where nil is expected, however say I want to build my package on a different machine, I would run into that machine not having my patched version of the package.</p> <p>What is the best practice in cases like this? I&#39;ve forked the aforementioned project and started applying some fixes and even set up CI to test it automatically. Should I just fork the package that&#39;s using the dependency, update it and use my local version? That would put back all the overhead of having to check for updates and merging manually, which is why I started using a framework in the first place. What is the best practice in this case?</p> <hr/>**评论：**<br/><br/>natefinch: <pre><p>I&#39;m not sure I&#39;d call go-yaml abandoned per se... but it definitely needs maintainers that have the time to go through every PR and issue.</p></pre>danielkov: <pre><p>Exactly my thoughts. I would even offer my help maintaining the package, but I couldn&#39;t find any info related to that being a possibility.</p></pre>natefinch: <pre><p>I know the maintainers well, I&#39;m pinging them, and we&#39;ll see what we can do. </p> <p>Since this is basically the canonical (heh) yaml library for Go, it needs to be well-maintained.</p></pre>danielkov: <pre><p>That&#39;s nice of you. It&#39;s a great package in general imo.</p></pre>vorg: <pre><blockquote> <p>I want to build my package on a different machine, I would run into that machine not having my patched version of the package</p> </blockquote> <p>You can put the package in the vendor sub-directory at the top-level directory structure of your own package.</p></pre>danielkov: <pre><p>Thanks for the answer! I am actually doing that at the moment but I wanted to use a fork of the original package, which would have a different path. To try to solve this I used dep and added a source property to the package which points to my patched version, though because I did not directly depend on go-yaml, but gin did, it didn&#39;t do the magic for me. It seems that it&#39;s only doing a shallow dependency management and does not really take care of chains as much.</p></pre>Veonik: <pre><p>You can add go-yaml to your project explicitly with this in your Gopkg.toml:</p> <pre><code>required = [&#34;gopkg.in/yaml.v2&#34;] </code></pre> <p>I&#39;d presume that that directive, in addition to your source property under go-yaml&#39;s constraint section, would take care of you.</p></pre>danielkov: <pre><p>It seems to ignore the constraint when I specify the package as required. I&#39;m not too familiar with dep yet, sadly.</p></pre>