On Thu, Mar 4, 2021 at 9:54 AM Michael Ellis <michael.f.el...@gmail.com> wrote:
> On Thursday, March 4, 2021 at 2:24:11 AM UTC-5 axel.wa...@googlemail.com > wrote: > >> On Thu, Mar 4, 2021 at 12:55 AM Michael Ellis <michael...@gmail.com> >> wrote: >> >>> Thanks even though it's not the answer I was hoping for. Seems to me >>> that since the Go Authors have accorded special status to directories named >>> "internal" the module mechanism should recognize references to it and not >>> require a globally unique path string. >>> >> > >> >>> >> Maybe. There seem to be few downsides. Then again, your case is also >> fairly special. >> > > Not sure if my case is all that special. Seems like the requirement for a > full path to an internal package breaks the concept of "internal" because > it gives everyone import access to whatever the internal package exports. > It would be good to have Russ and/or Ian weigh in on this. My feeling at > this point is that either "internal" should be deprecated or the module > mechanism needs to honor it. > I don't understand what this even means. You're saying that you have some API for constructing a paired server component and WASM client, and the way that projects use that API is by swapping in their own "internal/common" package. That *already* fundamentally breaks the concept of “internal”: the "internal/common" package is a public feature of the API, not an internal detail. > On Thu, Mar 4, 2021 at 3:34 AM 'Bryan C. Mills' via golang-nuts < >> golan...@googlegroups.com> wrote: >> >>> You should be able to use a `replace` directive to replace the full >>> path "github.com/Michael-F-Ellis/skeleton/internal/common" or similar. >> >> >> Using replace would still mean that a module doesn't work, when used as a >> library. Generally, I feel that `replace` is being used for more and more >> things it wasn't designed for, leading to more and more friction and >> problems. I don't think we should encourage more off-label uses. >> > > Agree. Replace in this instance feels like a hack. Don't get me wrong, I > like the concept behind go.mod and think it's generally a strong and useful > design. That being said, I also agree with the sentiment expressed in a > couple of other recent thread that the present implementation imposes a > burden on coders who want to quickly sketch and test ideas in a local > directory. It ought to be possible to progress at least a little way > beyond Hello World before needing an external repo. > I would argue that the “hack” in this case is the approach of defining the API in terms of copying in an entire tree of packages, rather than having users of the API make function calls into a specific set of (unmodified, un-relocated) packages with stable import paths. If the API is defined in terms or reflection over a set of types, why substitute a package rather than (say) having the caller pass in a set of instances of `reflect.Type` or similar? -- 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/CAKWVi_Tws%2BQ%3D%3Djfm-exHsE6%3DuGdoitFGBgW9i7FFmSm7eFFfRQ%40mail.gmail.com.
