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 workspace. Its a terribly boring issue when that happens, but i managed to survive it.
With a bit of research into those tools documentation, a solution should quickly come up to recursively update a workspace. About the deprecation, i think it is strongly dependent with your development practices and workflow. If possible, I would not deprecate, but update my dependencies, and pay my technical debts asap. As for go.loader, it is a high level API of go.ast, go.parser etc As such it provides lots of help when you are dealing with go language loading, parsing, interpreting, traversing and manipulation. It is tremendously useful when, for example, cross package reference resolutions comes into your way. Regarding the linkname pragma, i don't know enough about the process of compilation to tell you anything relevant to its usage. However, i tried to "relink" a public var of a package to another package public var, nothing happened. More reasonably, this extract (https://gist.github.com/myitcv/e4202a9513bed098262444ed0f4f3625) of pragma usage within the core tree demonstrates a pretty specific usage to inject public symbols of C funcs. e.g. //go:linkname byteIndex strings.IndexByte Maybe someone else with a deeper knowledge can help you figure that out. I don't have the feeling that i answered your questions, sorry for that. Le lundi 16 septembre 2019 15:57:54 UTC+2, Michel Levieux a écrit : > > 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 it can be > removed. > > I also find it important to specify that my program documents the whole > new package as being deprecated, also informing the user where to find the > new package. > > However, what I'm having trouble with is that a modification of a package > scope variable in the newly created package will not result in a > modification of the aliased variable of the old package. > I'm using the go/ast and go/parser (along with a little of go/token) > packages for the parsing, processing and generation of the different > aspects of the packages. > > I saw some //go:linkname pragmas that seem to do what I want but I don't > wanna do things that are not recommended or unsafe, I want to be sure what > I'm doing is the right way to go, or at least that it's not possible with > the current state of the language. > > > > Le lun. 16 sept. 2019 à 15:10, clement auger <clement...@gmail.com > <javascript:>> a écrit : > >> 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 found out. >> >> Le lundi 16 septembre 2019 14:27:01 UTC+2, Michel Levieux a écrit : >>> >>> Hi all, >>> >>> I'm developing a command that is a utility to move packages around while >>> keeping compatibility with softwares that import those packages. Maybe >>> there are commands and utilities that already do approximately the same >>> thing, but I'm mainly doing this to learn to use the go/ast package and >>> everything. Let me give you a small example: >>> >>> - Let's say I have a package in my GOPATH that's named 'foo' >>> - In this package there is another package 'bar', but this package bar >>> has grown a whole lot since the beginning of the project, and might as well >>> be a project on its own. >>> - What I want is extract package 'bar' from 'foo' without having to go >>> through all other projects importing 'bar' to change import paths >>> - The process for the command is to first move package 'bar' wherever I >>> tell it to move it and replace anything in previously existing package >>> 'foo/bar' with bindings, so any function's body is replaced with a call to >>> the function in the moved package, any type is transformed into an "alias" >>> of the moved package's corresponding type (TypeA = bar.TypeA), as well as >>> any constant or variable. >>> >>> The command is not finished yet but I'm running into a certain issue I >>> can't find a solution to: >>> >>> Whenever the command creates a binding for a given exported variable: >>> >>> var ( >>> Anything = 5.0 >>> ) >>> >>> becomes >>> >>> var ( >>> Anything = bar.Anything >>> ) >>> >>> there's a risk that bar.Anything was originally changed during the >>> program's execution and according to the context. If that was the case, any >>> change to bar.Anything will not be applied in foo/bar.Anything, which >>> breaks the whole thing. >>> >>> Does anyone have an idea how to programmatically make it so that any >>> changes applied to bar.Anything is applied to foo/bar.Anything, as if they >>> really did share the same memory? Of course this would need to be totally >>> transparent to the user of the package. >>> >>> Maybe this is not possible but if you guys know anything, please tell me. >>> >>> Thanks in advance! >>> >>> >>> -- >> 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 golan...@googlegroups.com <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/golang-nuts/099b1934-f90f-492a-a620-04c51599a70e%40googlegroups.com >> >> <https://groups.google.com/d/msgid/golang-nuts/099b1934-f90f-492a-a620-04c51599a70e%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- 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/d9b2521e-a99a-4caf-be47-6770d3760082%40googlegroups.com.
