Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The dependency could have easily been avoided by forking the repo which you're using, and using that instead. Obviously the maintainer(s) of the original will be making changes, so wouldn't you want to make sure that if you're distributing the code, you're all on the same version?

> Why does this matter?

Maybe I'm not understanding this, but the dependency issue and the issues in this paragraph are not related. Issues like improper syntax? That's not related.

Sounds like bad planning as far as the dependency stuff goes. For everything else, sounds like a distribution issue.




Let's say I depend on github/A and github/A depends on github/B. If I fork A, that does not solve the problem. Now I need to fork B and modify import paths in A to resolve my fork. Wouldn't this be a mess in time?

I assume, instedad of forking, it might be possible to import a specific tag, or commit hash from a git repo. If it's possible, it'd solve the backward incompatible change problem but I guess the original author can always delete the github repo.

What is a good way to manage dependencies locally?


I hadn't considered the A/B issue, and yeah that can get messy. Importing a specific commit hash to the repo would be great. As far as managing dependencies locally, I couldn't say since I haven't had much experience with Go, but there exists a package manager called "Go Nuts" (see: http://www.gonuts.io/). While obviously not widely used, it seems to fix this issue. It's almost like rubygems all over again though.

What I'd like to see is a site similar to this, with a similar tool. Instead of having to upload the package to the site though, you could add a `pkg.json` file (or something similar) with application data. Every time this is committed, the site would automatically check to see if the version has changed, and then index that commit hash as a new version.

This almost sounds fun...




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: