Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Change import path to github.com/ugorji/go-codec #43
It would be nice if the import path mapped directly to a URL to the source code.
Currently, it doesn't, and for no good reason. Initially, we used a repository name of go, with the
The plan of action is:
The new codec/fail.go file will contain
We hope to do this soon, likely by the end of january.
Adding on to other comments above from last year, remedying the compatibility change is quite easy, and renaming the repository would be much cleaner for consumers of it.
I feel like everybody should be able to search and replace using their favorite tools to change the import paths pretty easily.
If that's concerning though, could you alternately fork the repo to go-codec, move things around to make it the way you want it, and then make go-codec the canonical repo for these codecs? That way consumers of the package can migrate to the new repo name on their own time, and the old repo can be deleted eventually.
Currently, per sourcegraph, over 400 repositories depend on this library. Making such a change will be extremely disruptive to folks.
Unfortunately, I have thought long and hard about this, and there's no clean way to do it without un-necessary disruption. I liken this to backward-compatibility: sometimes it sucks, but it is necessary to carry forward.
Closing for now.
referenced this issue
Nov 28, 2018
The following was referenced in #275.
This was left unanswered in the prior closed issue, but is there some reason why you don't just keep the original repository name, and just add another repo as go-codec?
You can setup git to push to two different remotes at the same time so it really doesn't cost you anything (such as having to double-maintain), and since the repository name is optional (a user can choose to use the suggested name or the prior backwards-compat name), it really doesn't affect users/stale-projects and hence doesn't affect backwards compatibility during building in any way.
But this way at least people have an option to migrate to the new name over time. A number of your forks exist explicitly for renaming it to "go-codec" or "go-msgpack", so your users have definitely recognized that your initial project name "go" was a mistake. You could even point people to the https://gopkg.in url of your project in your docs to include the version as part of the package name.
This library is pretty much yours so you can do whatever you want with it of course, but there will definitely come a time when you will stop maintaining this project. And if this project follows the traditional open-source lifecycle, then someone else will likely inherit it. If somebody else implements a project called "go-codec" then they also have the option to impersonate your project. Before that happens, however, it'd be nice to get a solution for that the namespace collision available before that point happens I guess.
Anyways, it's all up to you of course. I just saw the comments/discussion that happened and don't think that aliasing the name of a project written in a relatively young language such as go is as intrusive as one might believe.
(edited to remove some unnecessary verbiage)
In retrospect, I am sort of happy that this change wasn't done, for the following reasons:
Let me hit on each one by one
With modules, it is possible now to have multiple packages inside the same repository.
Also, we now have some precedent with the https://github.com/golang/tools, which is a single repository that hosts the source for multiple tools managed by the core go team, including blog, cover, godoc, imports, present, playground, etc. Module support will help version the different tools, even though they all are hosted in a single github repo.
This also aligns with the way I hear code is stored in google and facebook, and the react library, in a single mono-repo.
The analogy is that my go code that I share with the world is stored at github.com/ugorji/go, and includes the codec library, codecgen tool, etc.
That's one part.
If we change the package name, then every user has to update their code, or we split the userbase into old and new. We see how that has not worked out well when folks do it, and my package is not as popular that everyone will happily bite the bullet.
Look at https://godoc.org/github.com/ugorji/go/codec (scroll to the bottom): it says that my package is now used by 2214 packages. That is way too much to force a change to. And we still have no defined way to make announcements.
Source code churn
Changing the package name involves moving everything one directory up, which completely messes up the git history. I don't want to do it unless I have to.
For these reasons, making the change is a no. Folks are generally ok with it, and the ecosystem (with modules, etc) now encourages this model of a single repo containing multiple packages - unlike before where this wasn't truly supported.
Hope this helps explain the position.
In the future, I hope a service comes that provides true canonical package names in a flexible way. Currently, the "import paths metadata" doesn't support this, as it still expects that the canonical name and the repo have the same base path. Consequently, I can use it to map domainName/go/codec to github.com/ugorji/go/codec, but not to map domainName/go-codec. I would hope that the "godoc.org" service provides something like this, but it requires more flexible support from the go tool first.
I may follow up on this with the go tools teams in the future.
Fair enough. Extending on your points though:
Tbh, I prefer your method of using
As an example, like even tho you want to complete deprecate
Anyways, thanks for your work on
(edited to mention
Honestly, my biggest concerns are source code churn and compatibility.
If I change the repo name, then I am suggesting that folks change the import path in their codebase. This effectively splits the ecosystem, which go doesn't allow. I cannot have the same codebase support github.com/ugorji/go-codec/codec and github.com/ugorji/go/codec . This is even more critical with the advent of modules, where you MUST specify the module name in the go.mod file. This is why the "import path" comment was created since go 1.4, so that you could have an "alias" but enforce a single import path.
Source code churn
If I change the import path, then I WOULD like to remove the codec subdirectory, and move everything one directory up. That means that "github.com/ugorji/go/codec" would move to "github.com/ugorji/go-codec" with package name "codec". This would cause unnecessary source code churn, and cannot be solved while solving compatibility above i.e. it goes against compatibility above.
I am currently considering a middle ground - but am not sold on doing it yet.
This way, we change the repo name to match the function of the repo. Yet we maintain compatibility and have no source code churn.
I do not want to use submodules because they bring inconvenience, but seen now and unknown. Some of these concerns are nicely articulated at the bottom of https://github.blog/2016-02-01-working-with-submodules/
This needs to be addressed asap. You pushed a breaking change in early march (moving the location of
This is a VERY big issue now that you have released another tag with this breaking change. Because you define your import path as
edit dep will, thanks to the [[override]] block, but mod just produced headaches. I really hope something can be done here.
I am sorry if I sound harsh, but I have been fighting this for a month now and I grow weary of it.
@dcarbone While I can understand the tendency to lash out when frustrated, I cannot accept this here. Next time you need to sound harsh and lash out, close a door and scream. Then compose yourself and make your point. It will go down much nicer next time.
This is the way this works, and anyone that has submitted a bug report can attest to this. You find an issue, you describe it, I resolve it typically within a few days. There's a reason why the bug count is typically about 0 (save for these reminder bugs I keep around).
Do us all a favor. Next time something bothers you, articulate your issue swiftly - and watch it get resolved very quickly. If you had brought the issue to my attention earlier, we might have resolved it before it stayed for so long. The main issues here is that I forgot that folks would use the literal constructors, and so that code is broken. That is a big shame - I wish someone had raised the flag early since I didn't realize it.
About the other thing i.e. dep and mod having an issue with the module path of github.com/ugorji/go - articulate your issue well in a new bug and I can try to address it. It may be as simple as putting a holder file in the module path.
But I can't afford this ridiculousness you did above. Behavior like that serves only as a detriment to the entire community, as it discourages folks from doing good work for free.
Hope this message reaches you well.
I believe I articulated my issues very concisely. Using go mod, it is not possible to constrain this package properly as there is no code present in the path defined by the mod file. In addition, you cannot merely use a typical [[constrain]] block in a Gopkg.toml because, again, there is no code in the root of the repo. The same goes for Glide. All of these issue would be fixed if you were to change the package path as defined in this issue.
If you really want, I will open separate issues.
referenced this issue
Apr 12, 2019
Many tools e.g. travis-ci, etc do not work well with a repo name different from the import path. It prevents us from getting this testing with multiple versions of go officially. Due to this, I will revert the repo name back to go.
Travis CI supports this well via the
Look at .travis.yml of github.com/go4org/go4 for an example of a repository with a vanity import path using it.