Hello, are there any updates on this issue? I've faced this problem too when I tried to make my own fork of a large go library with a lot of self-imports inside - do I actually need to rename all these imports inside for it even to compile?
On Sunday, December 30, 2018 at 10:11:12 AM UTC+2 Sotirios Mantziaris wrote: > I will try some of the suggestion in this topic to see what works out. > I will open a feature request in the golang repo for forking support. > > On Saturday, December 29, 2018 at 6:56:32 AM UTC+2, Nathan Fisher wrote: >> >> TLDR >> >> > Is it possible to fork a repo and change the import path of the >> repository? >> >> Not in one step with the github “click to fork”. You need to do one of >> the following: >> >> 1. Create a new empty remote repo, remap imports, and push to the new >> remote. >> 2. Fork, update imports, push. >> 3. Assuming vanity URL is used, fork and then update the vanity urls meta >> tag. >> >> > Is it possible to have: >> > both repos >> yes but I would try to deprecate one as “archived/historical”. >> >> > every repo with it's own import path >> yes, it does by nature of being different urls >> >> > code exchange between them >> yes, but I’d avoid if possible. You’ll need to remap imports to match the >> repo so it’s not a simple push to both remotes. >> >> — >> >> You can use gofmt to remap the import paths. If you’re aim is to “sync” >> repos (I’m not clear why you’d want this aside from a clearance process for >> making corp stuff public) then you could encode the commands in a script or >> make target and trigger them as part of a “publishing process”. Relative >> import paths were available at one point but they are now >> deprecated/unavailable. In theory it allowed ignorance of the SCMs root at >> the sacrifice of not being go gettable and probably a number of other >> issues which resulted in its removal. >> >> Godoc isn’t essential infrastructure in my opinion, you can serve docs >> locally in a pinch and I often do this while working offline in planes, >> trains, and automobiles. Introducing a registry however adds a failure >> domain/security concern that can break or be compromised. If githubs down >> and your repo is on github it’s the same failure domain so you’re arguably >> no worse/better off if your deps are there. Committing vendor where >> possible minimises the failure domains further and generally yields faster >> CI builds as a side benefit IME. >> >> Another option might be abusing vanity urls if the objective is to >> support ongoing development in both repos (eg returning different meta tags >> based on a work IP vs not or a local /etc/hosts override to a different >> vanity url host). I’m not terribly familiar with them but in theory it >> should allow the same import path in both repos but it would likely result >> in some confusing issues. I don’t think it’s a great idea but it might work >> for your scenario. >> On Fri, Dec 28, 2018 at 18:24, Sotirios Mantziaris <smant...@gmail.com> >> wrote: >> >>> If i understand it correctly the proposed solutions does not solve the >>> problem of forking repos. >>> The ideal solution would be to have a import path agnostic of the repo >>> location so that a fork could be up and downstream compatible. >>> >>> On Thursday, December 13, 2018 at 12:32:11 AM UTC+2, Ian Lance Taylor >>> wrote: >>> >>>> On Wed, Dec 12, 2018 at 8:08 AM Robert Engels <ren...@ix.netcom.com> >>>> wrote: >>>> > >>>> > I am pretty sure that the correct solution is to decouple the package >>>> from its location. And a global Go registry can tell Go get where that >>>> package can currently be found. >>>> >>>> You don't need a global registry. Or, rather, the global registry can >>>> be DNS. You can set up your own trivial redirector, using a meta tag, >>>> as discussed at https://golang.org/cmd/go/#hdr-Remote_import_paths . >>>> Or you can use an existing general purpose redirector such as >>>> gopkg.in. Either way you can enforce this with an import comment as >>>> discussed at https://golang.org/cmd/go/#hdr-Import_path_checking . >>>> >>>> Ian >>>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "golang-nuts" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to golang-nuts...@googlegroups.com. >>> For more options, visit https://groups.google.com/d/optout. >>> >> -- >> - sent from my mobile >> > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/3b42f072-ae99-4f67-bec4-a71d3683e55dn%40googlegroups.com.
