Just to close the loop, I've got a solution that's working well enough for my personal use.
It takes advantage of GitHub's Template repo feature and the gh CLI tool to simplify the process of creating a new repository with a clone of the skeleton and a local copy thereof. Using Axel's suggestion (thx!), I added an Init section to the magefile to walk the project tree changing any import references to match the new repo before building the app for the first time. Thanks again for the help and explanations. On Thursday, March 4, 2021 at 11:46:49 AM UTC-5 Michael Ellis wrote: > On Thursday, March 4, 2021 at 11:01:06 AM UTC-5 [email protected] > wrote: > >> On Thu, Mar 4, 2021 at 4:51 PM Michael Ellis <[email protected]> >> wrote: >> >>> My bad. I should have tested before writing that. Thanks for checking. >>> Good to know the tools are enforcing the distinction. Still, the import >>> path requirement does get in the way of being able to create a new >>> application by cloning and revising an existing one without doing a >>> recursive sed (or equivalent thereof). >>> >> >> I agree :) And as I said, we could probably make relative imports work. >> But currently, the mapping from import paths to packages in a single go >> binary is 1-1. If we would allow you to use relative imports *as well,* >> that would be lost. Or we would have to force you to do one *or* the >> other per module. Either way, it seems like a non-trivial and potentially >> confusing transition. At which point we get back to "your usecase seems >> fairly special". Not "using internal packages", but the entire "cloning an >> existing project/skeleton and expect to have that just work as the >> jumping-off point for a new one". Note that *some* search/replace like >> stuff is still going to be needed anyway - at the very least, `go.mod` >> needs to contain a user-chosen module path. >> >> That's why I really don't think it's worth changing. Overall, your >> use-case seems much better addressed by writing a tool that generates your >> skeleton, replacing paths as needed, instead of expecting `git clone` to >> serve that purpose. >> > > Ok. Thanks for coherent explanation of why it may be hard to support > relative imports. The skeleton code already has a fair amount of code > generation at build time, so it's not unreasonable to add an "Init" target > to the magefile that modifies go.mod. I'll look into ways (build tags?) to > avoid using internal if possible. > > I disagree that cloning and modifying existing projects is special. Good > lord! I (along with about a million other engineers) have been doing that > for decades:-) My clients really don't want and shouldn't have to pay me to > start from scratch every time. > > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/f29b9eaa-a8cc-49aa-9291-db77e81c06b0n%40googlegroups.com.
