Hi Sean! Thank you very much for your answer! After trying out some other options [and calming down], I realized I could indeed just remove the go.mod completely and still have the wiring be functional. For exposed constants (fortunately we didn't have exposed global variables), I just reported the old package.
So everything works well now :D Thank you again, Le lun. 20 déc. 2021 à 19:24, Sean Liao <seankhl...@gmail.com> a écrit : > You're right about the source of the error you're seeing (subfolder of > root + independent module). > If you just want to get rid of the error, update your versions of the 2 > modules so they both have the same view of module boundaries. > But you don't need 2 separate modules for this, > and you probably shouldn't as your downstream consumers can now have the 2 > packages in different states of migration. > For most things (functions, types) you can just move them and provide > either wrappers or type aliases at the old location. > It's only global variables that well be hard to move. > > > On Monday, December 20, 2021 at 5:39:00 PM UTC+1 mlevi...@gmail.com wrote: > >> Hi all, >> >> I have a use-case which I'm not sure I'll be able to tackle using current >> tooling but just to be sure, I'm asking here. >> >> I have a package which originally looked like: >> / >> /go.mod >> /package_name >> /other_packages... >> >> there are no go files at the root of the module, and the code that is >> "meant" to be used (understand "exposed") is located in /package_name. The >> /other_packages are in fact internal ones. >> >> I'm currently refactoring this all to: >> - put all go files that constitute the package we want to expose at the >> root of the module >> - add an internal/ folder to handle not-exposed features and helpers >> - other changes like performance, more idiomatic go... >> >> The problem I have is that we need to be compatible with current code >> using the /package_name during the process. So what I originally came up >> with is: >> >> / >> /go.mod // for the module and main package >> /package_name // for compat, wired into new package >> /package_name/go.mod // with a single dependency -> the root of the module >> /internal/ >> /internal/other_packages >> /go files for the correctly exposed new version of the package >> >> I was in the optic of updating the go.mod in /package_name regularly to >> see if my refactoring was not breaking anything. But now `go mod` has a >> problem: it finds the package /package_name in two different places: >> - one in /package_name/go.mod - the one that's being kept for >> compatibility >> - one in /, the root, which has a sub-package /package_name >> >> It feels like the problem is having two distinct go.mod, one in a >> subfolder of the root of the module, but I have difficulties wrapping my >> head around all that... If anyone has a clue what I should do, or what I'm >> doing wrong, I'll be happy to take it! >> >> Thanks! >> >> >> -- > 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/25bda8b6-9329-459b-902c-4f06072bda3cn%40googlegroups.com > <https://groups.google.com/d/msgid/golang-nuts/25bda8b6-9329-459b-902c-4f06072bda3cn%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/CAL4P9zxm9b6CukvMS5ZBcHH2MANU8gQiY3es23d64VEL5uy9Zw%40mail.gmail.com.
