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

Make github.com/umputun/reproxy/lib a submodule #117

Open
ShoshinNikita opened this issue Nov 15, 2021 · 2 comments
Open

Make github.com/umputun/reproxy/lib a submodule #117

ShoshinNikita opened this issue Nov 15, 2021 · 2 comments

Comments

@ShoshinNikita
Copy link
Contributor

Import of github.com/umputun/reproxy/lib adds github.com/umputun/reproxy to go.mod. It results in a significant number of dependencies.

At the same time, github.com/umputun/reproxy/lib requires only 3 dependencies:

  • github.com/go-pkgz/lgr
  • github.com/go-pkgz/repeater
  • github.com/stretchr/testify

Making github.com/umputun/reproxy/lib a submodule can resolve this issue.

However, this change will also require some additional work:

I don't think these points are very critical: API of github.com/umputun/reproxy/lib is pretty stable, and the current version (v0.10.0) allows to make breaking changes

@umputun
Copy link
Owner

umputun commented Nov 15, 2021

this is a valid concern. Making submodule in go is smth awkward a little bit with an additional tag we will have to maintain for lib. However, breaking dependency to the github.com/umputun/reproxy is worth it in my opinion.

I'm not sure I understand the meaning of "will have to be vendored" item. Does it mean vendored by reproxy itself because it will be treated as a module and won't be resolvable "directly" anymore? Are you saying this won't work anymore unless vendored?

zcqje-202111-15155123-4k00w

@ShoshinNikita
Copy link
Contributor Author

Does it mean vendored by reproxy itself because it will be treated as a module and won't be resolvable "directly" anymore? Are you saying this won't work anymore unless vendored?

Yes, you are right.

From golang/go#33789:

At the moment, this is working as designed: go mod vendor doesn't know (or particularly care) about the overall repo structure — it just knows where the main module is and vendors in the dependencies of the main module wherever they are found.

Some workarounds:

But as I said, github.com/umputun/reproxy/lib should be pretty stable. So, I don't think it will be a big problem

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

2 participants