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

package management: Plans to migrate to dep? #15145

Closed
VoR0220 opened this issue Sep 13, 2017 · 5 comments
Closed

package management: Plans to migrate to dep? #15145

VoR0220 opened this issue Sep 13, 2017 · 5 comments

Comments

@VoR0220
Copy link
Member

VoR0220 commented Sep 13, 2017

Any chance of migrating go-ethereum to using dep? Seeing as it's aiming to be the package manager to end all golang package management problems, seems it would be useful to begin utilizing it.

Any objections to using it? Seems it's basically ready to rock...although the secp256k1 issues might create some issues in the short run.

https://github.com/golang/dep

@karalabe
Copy link
Member

We've switched dependency management quite a lot until we arrived at the current govendor setup that works for all corner cases. What would be the added value of dep to warrant yet another switch? Given that it's still considered experimental, I don't really see why we should move.

@VoR0220
Copy link
Member Author

VoR0220 commented Sep 14, 2017

couple reasons:

a) It's going to be in the official golang toolkit.
b) It has the efforts of the folks from all the various package managers across the golang space
c) Better handling of foreign repos (it has an algorithm that checks all available versions in it's "range" to make sure things don't break as it updates before settling on one "branch"). Could be slower but also very useful in terms of making sure external dependencies don't break the codebase.
d) It's safe for production use...so they say. Am skeptical about how this would work with secp256k1 specifically.

If those are not enough then perhaps it would be better to wait until it's more solidified.

@karalabe
Copy link
Member

I don't mind switching to a "standard" tool once it's accepted as such. But we don't really have the capacity to experiment in this direction, and to debug any issues, hence why for the current moment I'd stick with our working system. But we should definitely revisit this once dep gets more mainstream adoption.

@VoR0220
Copy link
Member Author

VoR0220 commented Sep 15, 2017

Sure. It makes sense to play conservatively here. Should we keep this open for a revisiting at a later date or close for now?

@fjl fjl closed this as completed Sep 15, 2017
@fjl
Copy link
Contributor

fjl commented Sep 15, 2017

We will migrate to anything else if

  • it's strictly better
  • it's strictly more 'standard' and it can handle our use case

When this happens, the transition will be a no-brainer and we don't need to have an issue for it now.

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

3 participants