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
Closed

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

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

Comments

@krasi-georgiev
Copy link

@krasi-georgiev krasi-georgiev 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

@cznic cznic commented Mar 1, 2018

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

@krasi-georgiev

This comment has been minimized.

Copy link
Author

@krasi-georgiev krasi-georgiev 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

@cznic cznic 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

@krasi-georgiev krasi-georgiev commented Mar 2, 2018

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

@cznic

This comment has been minimized.

Copy link
Contributor

@cznic cznic 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

@kardianos kardianos 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

@krasi-georgiev krasi-georgiev 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

@cznic cznic 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

@rsc rsc 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
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants
You can’t perform that action at this time.