Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

consider using a package manager? #4

Open
bacongobbler opened this issue Aug 1, 2017 · 5 comments
Open

consider using a package manager? #4

bacongobbler opened this issue Aug 1, 2017 · 5 comments

Comments

@bacongobbler
Copy link

bacongobbler commented Aug 1, 2017

Hey there! First off I'd like to say thank you for writing this port of linguist to Go. It has saved me a ton of time writing one myself. ❤️

Now, with that out of the way, when first building linguist, one of the dependencies for this project was broken in master. because this project relies on go get to fetch the dependencies, building this project failed until I submitted this PR over to git4go.

I would consider using a package manager like glide or dep so future newcomers won't be bitten by issues like I did. Would you be amenable to a PR that provides a basic glide.yaml and installation instructions on how to build the project using glide?

@dayvonjersen
Copy link
Owner

At the moment, this project only has 3 third-party dependencies:

  • github.com/jbrukh/bayesian
  • github.com/shibukawa/git4go
  • github.com/jteeuwen/go-bindata

I'm not thrilled with the idea of adding yet another step to an already lengthy set of build steps.

Nor am I particularly enthusiastic about any of the vendoring options available at present (with the possible exception of gopkg.in). They require the users of your package to install another tool and most dump all the dependencies in the current folder and rewrite all your import statements (maybe idk that might not be the case anymore).

But in any case, it's a bit of a complication I'd like to avoid having to use, especially for a hobbyist project like this one. However, if it does indeed prove necessary (i.e. if there are any future incidents with broken packages) or if the Go team releases their official solution and if it's any good and if it ships with Go...

I mean, I'm not saying no.

I don't know what made @shibukawa decide to break their package after 2 years of rock-solid inactivity stability, but I hope they accept your PR and sort this out.

Otherwise there are three options:

  • vendoring
  • fork the repo and import that instead
  • revert this commit

None of which I want to do, to be quite honest.

-tso

dayvonjersen added a commit that referenced this issue Aug 9, 2017
 - Forked https://github.com/shibukawa/git4go
   to https://github.com/generaltso/git4go

 - git reset --hard HEAD~1 && git push -f
   (revert the changes that broke the package)

 - `import "github.com/generaltso/git4go"` instead of shibukawa/git4go

Note: I don't intend to maintain a separate fork indefinitely...
@technosophos
Copy link

Adding a glide.yaml or a dep file wouldn't force people to use it. Users could still use go get. But it would save people like me from spending two hours trying to figure out what happened when your dependency broke.

@bacongobbler
Copy link
Author

@technosophos just an FYI that the latest version of this repo just forked and temporarily resolved git4go's dependency issue, so it should not be a problem for people using master going forward.

@dayvonjersen
Copy link
Owner

If someone could provide an example glide.yml either as a comment or a PR I'd most likely add it.

That's what I've been trying to say this whole time but couldn't quite find the words :x

@ianlewis
Copy link

ianlewis commented Aug 28, 2023

I think adding a go.mod (in 19ca13f) basically solves this issue so I could be closed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants