Hi all,
@clement auger I've looked at your links and
they're all great, though the three last ones spoiled me a part of what I
still have to do in my own project ;)
Appart from that, I've already (quite successfully it seems) developped the
part of the program that is supposed to take care of r
hi Michel,
canonical import path ?
https://golang.org/doc/go1.4#canonicalimports
https://docs.google.com/document/d/1jVFkZTcYbNLaTxXD9OcGfn7vYv5hWtPx9--lTx1gPMs/edit
you also might want to check,
https://github.com/golang/tools/tree/master/cmd/gomvpkg
https://github.com/golang/tools/tree/master/
Hi again Clément,
It is indeed an uncommon practice, but I can explain my motivations behind
this little project:
Where I work, we have a huge helper package with lots of sub-packages. This
package existed long before I started working there, and we (the devs) knew
it would be a problem at some po
hi again,
This looks odd use case because when i move a package around,
with all the great tooling provided by the contributors,
import paths are updated automatically after a save.
It fails only if the package name is ambiguous because it
exists twice with different package paths within the works
Hi Clément, thank you for your answer,
Your links are pretty interesting, though maybe I was unclear stating my
issue because that is not what I was looking for.
I also think such a tool should be used with parsimony, the goal being that
over time, people stop using the old package's location and
hi,
it seems you need
https://godoc.org/golang.org/x/tools/go/loader
https://godoc.org/go/types
then select desired package, get its top scope, loop over public names,
generate aliases.
but i m unsure it is such a good idea to keep those shallow copies around,
at least for the case you have f
