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

x/vgo: A way to temporary NOT use a specific vendored package #24202

Closed
krasi-georgiev opened this issue Mar 1, 2018 · 9 comments

Comments

@krasi-georgiev
Copy link

commented Mar 1, 2018

currently I don't see any sane way to work on a vendored package without messing up the git workflow and confusing vscode.

Would it make sense to add support for using an env variable to allow ignoring a specific vendored package so that I could test an app using a different/modified dependency package?

I tried few workarounds like using .gitignore , --assume-unchanged etc , but none worked well so far when the vendored pakcages are tracked by git which is the case with all projects I have worked on.
On top of that vscode's file tree colouring also gets confused.

@bradfitz bradfitz changed the title A way to temporary NOT use a specific vendored package x/vgo: A way to temporary NOT use a specific vendored package Mar 1, 2018

@gopherbot gopherbot added this to the vgo milestone Mar 1, 2018

@cznic

This comment has been minimized.

Copy link
Contributor

commented Mar 1, 2018

Sounds more like a vscode issue, doesn't it?

@krasi-georgiev

This comment has been minimized.

Copy link
Author

commented Mar 2, 2018

that was only an example, but any IDE will behave the same , the main problem is the git workflow though.
The general rule is to never manually touch anything in the vendored folder, so the only way to do this and still make changes to a package would be like I suggested.

@cznic what is your git workflow when you make changes to a vendored package? I am happy to try any suggestions.

@cznic

This comment has been minimized.

Copy link
Contributor

commented Mar 2, 2018

Never ever used vendoring. I have no need for it. Seems like with vgo the support for vendoring may get dropped anyway.

@krasi-georgiev

This comment has been minimized.

Copy link
Author

commented Mar 2, 2018

without vendoring ,what happens if the source disappears or changes names?

@cznic

This comment has been minimized.

Copy link
Contributor

commented Mar 2, 2018

Nothing. It's on all my machines and in our Gitlab. But generally I try to avoid importing packages that may disappear or break.

@kardianos

This comment has been minimized.

Copy link
Contributor

commented Mar 2, 2018

vendoring isn't going away as an option most likely: https://groups.google.com/forum/#!topic/golang-dev/FTMScX1fsYk

Are you familiar with the go.mod "replace" directive?
https://research.swtch.com/vgo-tour (under Replacing)

@krasi-georgiev

This comment has been minimized.

Copy link
Author

commented Mar 2, 2018

@kardianos rock star!
it seems to address exactly what I am describing. I will try it shortly

@cznic

This comment has been minimized.

Copy link
Contributor

commented Mar 2, 2018

@kardianos Haven't yet read the vgo series except for part 1, unfortunately. But I thought I saw rsc expressed the intent to remove vendoring somewhere (reddit? ML discussion)? Not sure IIRC, though.

No difference for me anyway. Haven't used it before and I don't think that's going to change. I still consider vendoring a mistake.

@rsc

This comment has been minimized.

Copy link
Contributor

commented Mar 27, 2018

Replace is definitely what you are looking for, not modifying vendored copies directly (at least not if you want to preserve the changes; that might be fine for debugging maybe).

@rsc rsc closed this Mar 27, 2018

@golang golang locked and limited conversation to collaborators Mar 27, 2019

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
5 participants
You can’t perform that action at this time.