Gradual change of package path

[Levieux Michel]

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!

[Sean Liao]

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.

[Levieux Michel]

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,

--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/25bda8b6-9329-459b-902c-4f06072bda3cn%40googlegroups.com.