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

all: consider using golang.org/x/mod packages and removing duplicates #74

Open
dmitshur opened this issue Jun 29, 2019 · 4 comments

Comments

@dmitshur
Copy link

@dmitshur dmitshur commented Jun 29, 2019

Now that golang/go#31761 has been accepted and golang.org/x/mod is starting to get some of the same packages, I think it would make sense to start using them in this repository (and potentially removing duplicates).

For example, golang.org/x/mod/module now exists and defines the module.Version type. If someone uses that package in their project, the problem is that the types used in github.com/rogpeppe/go-internal/modfile are not compatible and need to be converted.

To make things better, github.com/rogpeppe/go-internal/modfile can be updated to use golang.org/x/mod/module directly and github.com/rogpeppe/go-internal/module can be removed.

Alternatively, github.com/rogpeppe/go-internal/module can be updated to define Version as a type alias of golang.org/x/mod/module.Version.

In my personal opinion, it would be most helpful if this repository contained only the bare minimum packages that are not available elsewhere, but that's a decision for the project owner(s).

@myitcv myitcv changed the title consider using golang.org/x/mod packages and removing duplicates all: consider using golang.org/x/mod packages and removing duplicates Jun 29, 2019
@myitcv

This comment has been minimized.

Copy link
Collaborator

@myitcv myitcv commented Jun 29, 2019

Thanks for the heads up (FYI we've been tracking this for a while, since @rogpeppe raised golang/go#28101).

The one thing we'll need to keep in mind is that we've already released v1 so we can't make any breaking changes.

@dmitshur

This comment has been minimized.

Copy link
Author

@dmitshur dmitshur commented Jul 1, 2019

we can't make any breaking changes.

I have a question about that. This repository is a copy of internal packages which may have breaking changes over time. Are you not planning to make breaking changes here if/when that happens? Or do you mean you can't make breaking changes in v1, but can in v2, etc.?

@rogpeppe

This comment has been minimized.

Copy link
Owner

@rogpeppe rogpeppe commented Jul 1, 2019

@dmitshur yes, the idea of this repo is that it provides a stable API even if upstream changes incompatibly, if possible.
If not, we'll just move to v2.

@dmitshur

This comment has been minimized.

Copy link
Author

@dmitshur dmitshur commented Nov 4, 2019

FWIW, this is becoming less of a problem now that more packages have been added to x/mod. It's possible to switch to using x/mod atomically and the packages there are naturally compatible with each other. For example, see shurcooL/home@dce9a6e. That means the value of doing the work to resolve this issue is lower now.

(Thank you for providing those packages before they were added to x/mod; it has been very helpful.)

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