Skip to content
This repository has been archived by the owner on Sep 9, 2020. It is now read-only.

Can dep resolve dependencies in other tools format (glide or godep for example)? #222

Closed
nvcnvn opened this issue Feb 3, 2017 · 9 comments
Labels

Comments

@nvcnvn
Copy link

nvcnvn commented Feb 3, 2017

Can dep read the configuration from Glide, Godep, GB, GOM, and GPM (currently Glide can do this)?

We now using Glide for all internal packages, if dep can read the configuration from some of the current popular community tools, this will help the transition to this new tool (in some day).

@sdboyer
Copy link
Member

sdboyer commented Feb 3, 2017

Not right now, but it could. Initially, implementing reading other tools is all about init - #186. However, code that's written for init is likely to be trivially adaptable to also be used at dependency resolution time.

In discussions about this prior to opening up the dep project, the committee was generally more in favor of not supporting old tooling at all (except at init), with the concern that it would have the unintended effect of encouraging the ecosystem to remain fragmented between different tools.

@peterbourgon
Copy link
Contributor

tl;dr: dep probably won't read Glide config out of the box, but probably will convert from Glide config.

@arthurnn
Copy link

arthurnn commented Mar 2, 2017

In discussions about this prior to opening up the dep project, the committee was generally more in favor of not supporting old tooling at all (except at init), with the concern that it would have the unintended effect of encouraging the ecosystem to remain fragmented between different tools.

I agree with that.
I think having some tools to convert from X to Dep would make sense.. those tools dont need to be part of dep even, they could be open source tools some create.

@sdboyer
Copy link
Member

sdboyer commented Mar 4, 2017

@arthurnn at present I'm hoping we can do it within dep, as I think that'll make for the smoothest community migration process - that's what #186 is about. But there are reasons that might not work out; if it doesn't, falling back to separate tools would be just fine.

@drafnel
Copy link

drafnel commented Jul 17, 2017

This is pretty much a deal breaker. If the projects I depend on are using glide, then how can I use dep if dep isn't going to read the glide.yaml of dependent projects during 'dep ensure'? Generally the upstart provides compatibility with the incumbent systems to ease adoption.

@peterbourgon
Copy link
Contributor

peterbourgon commented Jul 17, 2017

dep parses glide files, but medium-term, projects should convert from glide to dep.

edit: so I think we can close this issue?

@drafnel
Copy link

drafnel commented Jul 17, 2017

Is that a recent change? Because up above, sdboyer's comments seem to suggest that glide files are only read during 'dep init' and not during 'dep ensure'. And this issue (#821) was filed just a few days ago which is in-line with my own experience that dep does not seem to be using the glide.yaml files during 'dep ensure'.

@sdboyer
Copy link
Member

sdboyer commented Jul 17, 2017

yes, dep parses glide files, but only during dep init, and only the current project's glide files, not dependencies' glide files.

i'm going to close this one, though, as #821 is really a more detailed and complete writeup, and the use case described there convinced me that we definitely need to support on-the-fly conversion of dependencies' glide files during dep ensure.

@sdboyer sdboyer closed this as completed Jul 17, 2017
@archisgore
Copy link

Like others said, I moved to dep, but moving back to glide. I understand the need to discourage fragmentation, but when Google's own Kubernetes and GRPC is on Godep.json, it's a bit of irony that all our transitive dependencies get broken badly.

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

No branches or pull requests

6 participants