Re: [go-nuts] Re: Email threading package?

['Sebastien Binet' via golang-nuts]

There's that:

https://git.sr.ht/~emersion/go-emailthreads

(Quickly scanning the sources, it seems it "just" performs a topological sort, 
though)

hth,
-s

Aug 7, 2021 00:41:41 Tuhin Nair :

> Hey, this is a long shot but any chance you found a Go implementation for the 
> JWZ algorithm?
> 
> On Monday, July 20, 2015 at 6:14:32 AM UTC+5:30 a...@develooper.com wrote:
>> Hi,
>> 
>> Has anyone made an (open source) package to thread emails -- ideally a 
>> variation of http://www.jwz.org/doc/threading.html ? (I wanted to upgrade an 
>> old NNTP -> web gateway to Go to make it easier to maintain and it seems 
>> like nobody has done this part yet as open source -- or really much email 
>> parsing stuff).
>> 
>> Searching the internet for "golang email thread" (and variations) brings a 
>> lot of results referencing other email threads. :-)
>> 
>> 
>> Ask
> --
> 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/89dddc34-3bdf-4cc7-8503-3d43a36ab771n%40googlegroups.com[https://groups.google.com/d/msgid/golang-nuts/89dddc34-3bdf-4cc7-8503-3d43a36ab771n%40googlegroups.com?utm_medium=email&utm_source=footer].

-- 
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/ddc0e3bd-696f-48a6-9911-b7873a6b3b48%40sbinet.org.

[go-nuts] Re: Email threading package?

[Tuhin Nair]

Hey, this is a long shot but any chance you found a Go implementation for 
the JWZ algorithm?

On Monday, July 20, 2015 at 6:14:32 AM UTC+5:30 a...@develooper.com wrote:

> Hi,
>
> Has anyone made an (open source) package to thread emails -- ideally a 
> variation of http://www.jwz.org/doc/threading.html ? (I wanted to upgrade 
> an old NNTP -> web gateway to Go to make it easier to maintain and it seems 
> like nobody has done this part yet as open source -- or really much email 
> parsing stuff).
>
> Searching the internet for "golang email thread" (and variations) brings a 
> lot of results referencing other email threads. :-)
>
>
> Ask
>

-- 
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/89dddc34-3bdf-4cc7-8503-3d43a36ab771n%40googlegroups.com.

Re: [go-nuts] Re: What are the options to fake SQL database for testing?

[Amit Saha]

On Thu, Jul 29, 2021 at 5:13 PM Brian Candler  wrote:
>
> You might also want to look at podman, which runs containers directly as 
> processes under your own userid with no docker daemon - and buildah, the 
> corresponding tool for creating container images.  I use them quite a lot for 
> building and running container images before deploying them to kubernetes.
>
> I haven't used the go bindings, but apparently they do exist:
> https://podman.io/blogs/2020/08/10/podman-go-bindings.html

Thanks - I will check those out. I am looking for a solution which
will work across operating systems - Linux, Mac OS and Windows. Hence,
I suspect using the docker desktop might be a better solution for me.
I am leaning towards using tests containers go.
>
> According to that, they are running podman as a service with a REST API, 
> which isn't a million miles from a docker daemon - except that the podman 
> service runs as your own userid, not as root.
>
> On Thursday, 29 July 2021 at 06:23:05 UTC+1 amits...@gmail.com wrote:
>>
>> On Thu, Jul 29, 2021 at 4:39 AM Marcin Romaszewicz  wrote:
>> >
>> > I have this exact testing issue at my company, we have many Go services 
>> > which use Postgres in production, but are unit tested against SQLite.
>> >
>> > The latest SQLite covers the vast majority of Postgres queries, so most 
>> > tests simply use an SQLite in-memory DB.
>> >
>> > For the tests which require Postgres- specific functionality, such as 
>> > partitioned tables, for example, we use 
>> > https://github.com/testcontainers/testcontainers-go. This is a library 
>> > which talks to Docker and can create your test prerequisites as docker 
>> > containers and gives you connection information once they're up. This 
>> > makes unit tests incredibly slower, but at least functional.
>> >
>> > The danger with mocking too much is that your unit tests end up testing 
>> > the mocks, and not anything remotely like your runtime environment, so 
>> > we've chosen to mock as little as possible.
>>
>> Thank you for sharing about testcontainers-go. I have come across
>> testcontainers, it sounds like a viable solution as well. As with a
>> lot of things in software, it seems like we just have to see what
>> works for "us".
>>
>> >
>> > -- Marcin
>> >
>> > On Wed, Jul 28, 2021 at 4:09 AM Henry  wrote:
>> >>
>> >> On Wednesday, July 28, 2021 at 3:05:43 PM UTC+7 amits...@gmail.com wrote:
>> >>>
>> >>> That sounds interesting - is the tool generating or is able to
>> >>> generate SQL for different databases? That must have been a pretty big
>> >>> effort to create such an abstraction.
>> >>>
>> >>
>> >> It produces different SQL for different databases. It supports a limited 
>> >> number of databases. Note that quite a number of Go ORM libraries already 
>> >> support multiple databases. So it is not new. The difference is that 
>> >> other ORM libraries usually provide a general purpose data access 
>> >> library, whereas ours generates more specific codes. Other than that, 
>> >> they serve a similar purpose.
>> >>
>> >> --
>> >> 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/9c81746a-4fb4-4fb5-8e5f-605169a3f2afn%40googlegroups.com.
>> >
>> > --
>> > 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/CA%2Bv29Lv83-4yDijNmukf0Vx%2BoBVZXJPR11bqA_B5CY1mNhOowA%40mail.gmail.com.
>
> --
> 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/4d6f1b9d-ad44-4fc5-b309-beba2a199382n%40googlegroups.com.

-- 
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/CANODV3%3DxEQOWLWirXLS-75TGU15jWJhgRO_4%3D54%3DL5ZcuvQP4g%40mail.gmail.com.

Re: [go-nuts] Re: go install an/import/path@revision and /vendor in Go 1.16

['Jay Conrod' via golang-nuts]

Indeed, this should be better documented. I've mailed CL 340509
 to mention in a
couple places in /ref/mod that vendor directories are omitted from zip
files.

On Fri, Aug 6, 2021 at 3:55 AM Brian Candler  wrote:

> On Friday, 6 August 2021 at 11:46:24 UTC+1 Konstantin Khomoutov wrote:
>
>> On Fri, Aug 06, 2021 at 12:35:16AM -0700, Brian Candler wrote:
>>
>> > The key point I just learned from #40276:
>> > "Vendor directories are not included in module zip files."
>> >
>> > I found this surprising because -mod=vendor is now the default (here
>> > ) - therefore, I expected the
>> vendor
>> > directory, if present in the source, always to be used unless
>> explicitly
>> > disabled.
>>
>> An interesting point regarding our particular case - which I sadly failed
>> to
>> mention - is that we do not use any module proxies for own internal
>> projects,
>> and the hostname of our GitLab instance is listed in the GONOPROXY
>> environment
>> variable, so technically `go install` did not download a "classic"
>> module,
>> which is a ZIP archive file, but has rather performed the usual sequence
>> of
>> issuing a HTTP GET request with the "?go-get=1" query parameter followed
>> by a
>> shallow clone of the target Git repository.
>> Hence technically the "vendor" directory with its full contents was
>> available.
>
>
> However according to #40276:
>
> "Even when go connects directly to a repository instead of a
> proxy, it still generates zip files so that builds work consistently no
> matter
> how modules are fetched. Those zip files don't contain nested modules or
> vendor
> directories."
>
> --
> 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/9f4d48bd-fecf-46bf-aa85-5115f0513f53n%40googlegroups.com
> 
> .
>

-- 
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/CAGCADbbdnWR-WU-1YeyrsWwX2sreBkAmqrs-bzYwgFwrQL8FhA%40mail.gmail.com.

Re: [go-nuts] http.Response.Body.Close when ignoring the resp

[Andreas Götz]

Replying here as I was thinking about suggesting a go/vet check if the body 
is actually being closed. 

What I realise now is, that closing the body is just as good as not closing 
it as long as one doesn't read it first. As for reading there is probably a 
trade-off on when actually reading is still faster than establishing a new 
connection, either in latency or just cpu cycles/ power consumption.

Given that- I'm wondering if it weren't proper advise to just NOT care 
about closing the body unless you know for sure that you're interested in 
keep alives?

Cheers,
Andi

On Saturday, July 7, 2018 at 7:16:56 AM UTC+2 time...@gmail.com wrote:

> that's for sure. I has same issue, IF you don't close the body even you 
> don't care about that, the file descriptor won't close and lead to "too 
> many open file" error
>
> 在 2014年9月17日星期三 UTC+8下午3:28:34，Philippe Lafoucrière写道：
>
>> I had the same issue. I was not reading the body in most cases (only if 
>> there's an error, otherwise the body is an empty string on the distant API).
>> I was leading to leaking open files on the server, so I confirm, you MUST 
>> close the body, even if you don't read it :)
>>
>

-- 
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/c1ba134d-d6db-4252-917c-1d0e7ddde3bcn%40googlegroups.com.

Re: [go-nuts] Getting 502 errors in golang with heavy load

[Konstantin Khomoutov]

On Fri, Aug 06, 2021 at 08:13:46PM +0300, Konstantin Khomoutov wrote:

[...]
>  * Aerospike does not use HTTP as its client protocol; it implements some
>custom protocol over TCP sockets, so that 502

Sorry, fat fingers. I meant to say "... so that those '502 errors' could not
come from Aerospike". At least unless you're accessing it in some interesting
way, but then again - you did not tell us.

-- 
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/20210806171812.eqfyxmptawq2t2qx%40carbon.

Re: [go-nuts] Getting 502 errors in golang with heavy load

[Konstantin Khomoutov]

On Thu, Aug 05, 2021 at 08:07:58PM -0700, Anand vishnu wrote:

> my code is running absolutely fine with a smaller load, when load is 
> increased it is failing.
> The changes i made in the newer release tag:
> 1. pushing data to aerospike at each and every chunk
> when i turn off this line it is working fine , but when i turn this on it 
> is failing

Please consider the following set of facts:

 * While you did not explain that, "502 errors" appear to mean
   some HTTP requests complete with the server answering with responses
   containing the 502 HTTP status code.

   Sadly, you did not tell us which HTTP requests actually fail this way.

 * Aerospike does not use HTTP as its client protocol; it implements some
   custom protocol over TCP sockets, so that 502

 * HTTP status code 502 is defined to mean "Gateway Timeout".

Based on these facts I could do a guess: you have a setup like this:

 [your clients] → [http proxy] → [your Go program] → [aerospike]

Depending on how your Go server is deployed, you can be easily unaware that an
HTTP proxy - such as nginx - is sitting between your server and your clients.

When the load from the client increases, the request handling code starts to
spend progressively more time in the calls which send data to Aerospike,
and eventually some of them spend so much time doing that they surpass a
maximum time span configured in that HTTP proxy which any request is allowed
to spend. Once a request trips that threshold, the proxy rips it and returns a
response to the client, telling it the service it mediates access to is not
keeping up.

-- 
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/20210806171346.scqjtaju4ulwibkj%40carbon.

Re: [go-nuts] What's going on while using "append" in memory?

[Konstantin Khomoutov]

On Fri, Aug 06, 2021 at 12:42:34AM -0700, Miraddo wrote:

Hi!

> I can not understand why when we use append, it does not rewrite values in 
> the same address in the memory that it had before, 
> 
> (I'm not sure it "append" problem or the variable |  or just my problem for 
> sure :) ) 
[...]
> I saw all addresses in memory was changed, 
> 
> now my question is why it doesn't rewrite the values in the same address as 
> before?
[...]

Have you read and understood [1] and [2]?
I think the information from these articles will enable you to solve your
problem all by yourself.

I would also argue that rotating an array *in place* by a non-negative value
is "classically" solved by using a temporary variable and moving of the
array elements; the latter can be done by using copy().

 1. https://blog.golang.org/slices-intro
 2. https://blog.golang.org/slices

-- 
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/20210806165959.lwyefdc5daxlmp7y%40carbon.

[go-nuts] Getting 502 errors in golang with heavy load

[Anand vishnu]

Hi, 
my code is running absolutely fine with a smaller load, when load is 
increased it is failing.
The changes i made in the newer release tag:
1. pushing data to aerospike at each and every chunk
when i turn off this line it is working fine , but when i turn this on it 
is failing

-- 
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/437e1a39-b343-447c-8f5c-75041d8f17d4n%40googlegroups.com.

[go-nuts] What's going on while using "append" in memory?

[Miraddo]

Hello all, 

I can not understand why when we use append, it does not rewrite values in 
the same address in the memory that it had before, 

(I'm not sure it "append" problem or the variable |  or just my problem for 
sure :) ) 

let me explain what I mean, 

I solve a question in LeetCode (189. Rotate Array 
). The question said we give 
you an array, and you should rotate the array to the right by k steps, 
where k is non-negative.

I thought, so it's easy, we can do something like this :

```
func rotate(nums []int, k int) {
   nums = append(nums[len(nums) - k:], nums[:len(nums) - k]...)
}
```
When I used `fmt.Println` I got the right value; it was fine, but while 
running the test case, I got the same value as before, and it says so you 
didn't change anything there is still the same value as before, and it was 
completely wrong, 

after that, I rechecked my code; I did something like this :

```
func rotate(nums []int, k int) {

  for i := range nums{
fmt.Println(&nums[i], nums[i])
  }

 nums = append(nums[len(nums) - k:], nums[:len(nums) - k]...)

 fmt.Println("-")
 for i := range nums{
   fmt.Println(&nums[i], nums[i])
  }
}
```
the result was like this :

[image: Screenshot 2021-08-06 115209.png]

I saw all addresses in memory was changed, 

now my question is why it doesn't rewrite the values in the same address as 
before?

Could you please describe to me what's going on in memory, why it happened, 
and why it couldn't rewrite values in the same location in the memory? 

I don't have strong knowledge of what's going on in memory in Golang or at 
all. If there are any resources out there, could you please share them with 
me?

Thanks 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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/0c64f322-f55d-4063-9bb8-ca6f67d4fbccn%40googlegroups.com.

Re: [go-nuts] Why isn't go more popular?

[Mark Sinoberg]

can not agree more with u, go cool.

在2021年8月6日星期五 UTC+8 上午10:28:03 写道：

> On Thu, Aug 5, 2021 at 7:20 PM Santi Ferra
>  wrote:
> >
> > When you see the ranking of the most liked programming languages, go is 
> near c++, a really "hated app". But since is efficient and produces really 
> clean code, why no wants like it ?
>
> What rankings are you looking at?
>
> Ian
>

-- 
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/e3cd8eb3-3c63-45d6-a6dd-9272ceeb8566n%40googlegroups.com.

Re: [go-nuts] Why isn't go more popular?

[David Riley]

On Aug 5, 2021, at 10:27 PM, Ian Lance Taylor  wrote:
> 
> On Thu, Aug 5, 2021 at 7:20 PM Santi Ferra
>  wrote:
>> 
>> When you see the ranking of the most liked programming languages, go is near 
>> c++, a really "hated app". But since is efficient and produces really clean 
>> code, why no wants like it ?
> 
> What rankings are you looking at?

Seconded.  I would question those rankings, at least for code that's used for 
forward-looking purposes; in my experience, Go is rapidly replacing Java and in 
a number of cases Python for backend applications, and it has a lot of 
first-party support for things like API clients, telemetry, etc. that comes 
before those languages in many cases as well.

I feel like most people who dislike Go generally haven't used it. Having used 
it quite a bit, there are things I don't like a lot about it, but they're 
things that I feel like I can easily overlook given all the things it improves 
for me.  Those are the things people who haven't really given it much use tend 
to seize on, in my experience (e.g. "Go doesn't have generics", "Go doesn't 
really have a good way to make an iterator", etc.).

Rankings aren't generally very useful because they try to turn a massive vector 
quantity into a scalar for everyone's purposes, when in reality different 
people put different weights on things.  It's much more likely that you're 
seeing the effects of "which language is most used", and Go is a lot younger 
than most of the other languages in those rankings.


- Dave

-- 
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/92091078-2F36-4606-B3ED-BBA74957E17B%40gmail.com.

Re: [go-nuts] Re: go install an/import/path@revision and /vendor in Go 1.16

[Brian Candler]

On Friday, 6 August 2021 at 11:46:24 UTC+1 Konstantin Khomoutov wrote:

> On Fri, Aug 06, 2021 at 12:35:16AM -0700, Brian Candler wrote: 
>
> > The key point I just learned from #40276: 
> > "Vendor directories are not included in module zip files." 
> > 
> > I found this surprising because -mod=vendor is now the default (here 
> > ) - therefore, I expected the 
> vendor 
> > directory, if present in the source, always to be used unless explicitly 
> > disabled. 
>
> An interesting point regarding our particular case - which I sadly failed 
> to 
> mention - is that we do not use any module proxies for own internal 
> projects, 
> and the hostname of our GitLab instance is listed in the GONOPROXY 
> environment 
> variable, so technically `go install` did not download a "classic" module, 
> which is a ZIP archive file, but has rather performed the usual sequence 
> of 
> issuing a HTTP GET request with the "?go-get=1" query parameter followed 
> by a 
> shallow clone of the target Git repository. 
> Hence technically the "vendor" directory with its full contents was 
> available.


However according to #40276:

"Even when go connects directly to a repository instead of a
proxy, it still generates zip files so that builds work consistently no 
matter
how modules are fetched. Those zip files don't contain nested modules or 
vendor
directories."

-- 
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/9f4d48bd-fecf-46bf-aa85-5115f0513f53n%40googlegroups.com.

Re: [go-nuts] Re: go install an/import/path@revision and /vendor in Go 1.16

[Konstantin Khomoutov]

On Thu, Aug 05, 2021 at 04:39:00PM -0700, Sean Liao wrote:

> This is intentional and sort of covered by the statement that no module is 
> considered the main module (where replace directives and vendor dirs take 
> effect)

I must admit that sentence regarding the main module has caught my attention
when I was reading that part of the docs but it looks like I have not paid
enough attention to the concept of a main module earlier in the manual.
To be honest, I do not remember I have even seen it, no idea why.

> https://github.com/golang/go/issues/40276 has some more context

Thanks for your explanations.

[...]

-- 
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/20210806105206.h4m2azmsocjlxaqq%40carbon.

Re: [go-nuts] Re: go install an/import/path@revision and /vendor in Go 1.16

[Konstantin Khomoutov]

On Fri, Aug 06, 2021 at 12:35:16AM -0700, Brian Candler wrote:

> The key point I just learned from #40276:
> "Vendor directories are not included in module zip files."
> 
> I found this surprising because -mod=vendor is now the default (here 
> ) - therefore, I expected the vendor 
> directory, if present in the source, always to be used unless explicitly 
> disabled.

An interesting point regarding our particular case - which I sadly failed to
mention - is that we do not use any module proxies for own internal projects,
and the hostname of our GitLab instance is listed in the GONOPROXY environment
variable, so technically `go install` did not download a "classic" module,
which is a ZIP archive file, but has rather performed the usual sequence of
issuing a HTTP GET request with the "?go-get=1" query parameter followed by a
shallow clone of the target Git repository.
Hence technically the "vendor" directory with its full contents was available.

But yes, that point of yours is a sensilbe one; it sheds some light on the
reasoning behind the behaviour have observed.

[...]
> It might also be worth a mention at https://golang.org/ref/mod#zip-files 
> that vendor directories are excluded from module zip files (although I 
> wouldn't be reading that section if I was only interested in how vendoring 
> works)

I would say the doc could make use of some cross-referencing: this fact could
be mentioned either there or in the section on vendoring, and the remaining
section could contain a single statement about the fact with the link to a
full explanation in the other section.

What do you think?

[...]

-- 
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/20210806104542.2wmd7c3vfn6ohrt6%40carbon.

[go-nuts] Re: go install an/import/path@revision and /vendor in Go 1.16

[Brian Candler]

The key point I just learned from #40276:
"Vendor directories are not included in module zip files."

I found this surprising because -mod=vendor is now the default (here 
) - therefore, I expected the vendor 
directory, if present in the source, always to be used unless explicitly 
disabled.

It would be possible (although not a good idea) for someone to tweak their 
vendor directory contents directly, as an ad-hoc way of forking dependent 
packages.  This would work fine for local checkout and build, but fail for 
"go install".  Presumably they should import the code into a directory 
called something other than "vendor" in that case?

I think it would be helpful to flag this up 
at https://golang.org/ref/mod#vendoring

It might also be worth a mention at https://golang.org/ref/mod#zip-files 
that vendor directories are excluded from module zip files (although I 
wouldn't be reading that section if I was only interested in how vendoring 
works)

On Friday, 6 August 2021 at 00:39:00 UTC+1 seank...@gmail.com wrote:

> This is intentional and sort of covered by the statement that no module is 
> considered the main module (where replace directives and vendor dirs take 
> effect)
>
> https://github.com/golang/go/issues/40276 has some more context
>
> On Thursday, August 5, 2021 at 9:40:03 PM UTC+2 Konstantin Khomoutov wrote:
>
>> Hi!
>>
>> We have recently turned one of our internal Go projects into a Go module.
>> The project was using vendoring and we intend to continue doing so - just
>> rather with the natural support from `go mod` instead of govendor as 
>> before.
>>
>> An interesting issue came up when we've decided to try the recently added
>> ability of `go install` to grab a named module and build an executable 
>> from
>> it: we would expect that when we do
>>
>> $ go install an/module/import/path@latest
>>
>> the command would grab the module's source code (it's hosted by a GitLab
>> instance, so we'd expect the source code to be `git clone`-d) and then 
>> behave
>> as if one would clone the module's repository by hand and then run
>> `go install` in the local clone's work tree - that is, we'd expect the 
>> command
>> to actually make use of the vendored packages and not attempt to download
>> anything except the source code of the specified module.
>>
>> Instead, the command appears to read the module's go.mod file and then
>> download all the dependencies from the network - completely ignoring the
>> "vendor" directory of the module.
>>
>> I have tried to locate a related issue in the bug tracker, but failed;
>> [1] is the closest I was able to come up with, but it appears to not 
>> touch the
>> very problem I have described.
>>
>> The documentation also does not seem to specify the expected behaviour.
>>
>> Hence my question is: is this a problem worth reporting/discussing or 
>> just an
>> undocumented behaviour which is "by design"?
>>
>> My take on why this behaviour is confusing is that it makes `go install`
>> behave differently when it's apparently told to do the same thing to the 
>> same
>> module:
>>
>> - When I have the module's source code on my filesystem, and I run
>> `go install` in that directory, the command uses the vendored 
>> dependencies,
>> builds and installs the executable provided by the module.
>>
>> - When I run `go install import/path/of/that/module@revision`
>> I expect the command to just add one extra step - fetch the module's
>> source code and then run `go install` in the (temporary) directory
>> with the fetched source code.
>>
>> 1. https://github.com/golang/go/issues/44841
>>
>>

-- 
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/cc71c23c-9b20-4146-9c38-2c06763fc05cn%40googlegroups.com.