On Thursday, March 4, 2021 at 11:01:06 AM UTC-5 axel.wa...@googlemail.com 
wrote:

> On Thu, Mar 4, 2021 at 4:51 PM Michael Ellis <michael...@gmail.com> 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 golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/8f73006c-f3b2-42ee-a754-29d13bc5fa89n%40googlegroups.com.

Reply via email to