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 sugges
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 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
>>
On Thursday, March 4, 2021 at 10:06:01 AM UTC-5 Bryan C. Mills wrote:
>
> 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 (unmodi
On Thu, Mar 4, 2021 at 4:51 PM Michael Ellis
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 an
On Thursday, March 4, 2021 at 10:14:03 AM UTC-5 axel.wa...@googlemail.com
wrote:
> On Thu, Mar 4, 2021 at 3:54 PM Michael Ellis wrote:
>
>> 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
On Thu, Mar 4, 2021 at 3:54 PM Michael Ellis
wrote:
> 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.
>
Really? I can
On Thu, Mar 4, 2021 at 9:54 AM Michael Ellis
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
>> wrote:
>>
>>> Thanks even though it's not the answer I was hoping for. Seems to me
>>> that since the Go
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
> 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
On Thu, Mar 4, 2021 at 12:55 AM Michael Ellis
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 globa
You should be able to use a `replace` directive to replace the full
path "github.com/Michael-F-Ellis/skeleton/internal/common" or similar. If
you take that approach, the skeleton module itself *must not* contain that
package, or else the `import` statements that refer to that package would
be a
On Wednesday, March 3, 2021 at 6:11:38 PM UTC-5 axel.wa...@googlemail.com
wrote:
> On Thu, Mar 4, 2021 at 12:02 AM Michael Ellis
> wrote:
>
>> What's the right way to handle this use case?
>>
>
> I think the right way to handle it is to modify the file. In the final
> code, the import path s
On Thu, Mar 4, 2021 at 12:02 AM Michael Ellis
wrote:
> What's the right way to handle this use case?
>
I think the right way to handle it is to modify the file. In the final
code, the import path should unambiguously point to where the code can be
found - regardless of whether it was using your
I recently coded up a skeleton app to use as a starting point for projects
that include a server component and a wasm (WebAssembly) client that does
local work in a user's browser while communicating with the server.
The skeleton is hosted on Github (in a private repo until I think it's
rea
13 matches
Mail list logo
