Re: [go-nuts] proposal: infer module name via version control when running `go mod init`

[Jon Calhoun]

Sounds like this functionality was removed intentionally and will be a
no-go then. Thanks for sharing the link Jay!

On Wed, May 12, 2021 at 11:19 AM Jay Conrod  wrote:

> The go command used to infer the module path from .git/config for github
> origins specifically. However, that was removed in 1.13, based on
> discussion in #27951 <https://github.com/golang/go/issues/27951>. It
> wasn't a strong enough signal, and since it's important to get the module
> path right early on, it seemed better to require that the path be set
> explicitly when it can't be inferred from the location within $GOPATH/src.
>
> On Wed, May 12, 2021 at 11:01 AM Jon Calhoun  wrote:
>
>> I suspect that the VCS path gives nearly the same level of confidence in
>> practice. My personal experience shows that it is pretty rare for the two
>> not to line up, and when it does the developer made a conscious decision to
>> do so and knows to work around it.
>>
>> I'm also not suggesting that we remove existing behavior. go mod init
>>  is still valid so we don't lose robustness there.
>>
>>
>> On Wednesday, May 12, 2021 at 10:42:29 AM UTC-4 Bryan C. Mills wrote:
>>
>>> go mod init should only infer a module path when it can be certain that
>>> path is correct.
>>>
>>> For packages already stored in GOPATH/src, it knows the correct path
>>> with high confidence: the path relative to GOPATH/src is the path by which
>>> the packages in the module are imported when in GOPATH mode, so it is safe
>>> to assume the same path in module mode.
>>>
>>> On the other hand, a module hosted at a particular VCS path can be
>>> served through an arbitrarily different path using go-import
>>> <https://golang.org/ref/mod#vcs-find> metadata
>>> <https://golang.org/ref/mod#vcs-find>, and it could also be a private
>>> fork intended for use only with a replace directive
>>> <https://golang.org/ref/mod#go-mod-file-replace> (or intended to
>>> temporarily host a change while an upstream PR is outstanding). So we
>>> cannot assume that the VCS path necessarily corresponds to the module path
>>> — it seems more robust to ask the user to supply the intended path
>>> explicitly.
>>>
>>> On Wednesday, May 12, 2021 at 9:25:48 AM UTC-4 jonca...@gmail.com wrote:
>>>
>>>> After more thought, the proposal should be altered to only support git
>>>> in the first pass. It would cover a majority of users, wouldn't affect the
>>>> experience in other VCS, and would simplify the initial implementation.
>>>>
>>>> Doing every VCS at once would require someone learning how every VCS
>>>> defines the default remote repository (if it even does), and building off
>>>> that. It would be better to do each individually and let someone familiar
>>>> with each VCS take charge of that specific PR using existing VCS
>>>> implementations as a pattern to follow.
>>>> On Wednesday, May 12, 2021 at 7:28:11 AM UTC-4 ohir wrote:
>>>>
>>>>> Dnia 2021-05-11, o godz. 11:14:24
>>>>> Jon Calhoun  napisał(a):
>>>>>
>>>>> > it saves me a handful of keystrokes at best - so I understand if it
>>>>> doesn't seem
>>>>> > worth the effort.
>>>>>
>>>>> Right.
>>>>>
>>>>> > It feels close enough to the current behavior to be a good addition
>>>>>
>>>>> Gopath is retiring soon. Anyway, Someone needs to do many more
>>>>> keystrokes
>>>>> to int repository anyway.
>>>>>
>>>>> > , but I admittedly haven't explored how easy/hard it would be to
>>>>> implement.
>>>>>
>>>>> Look at the list of currently supported VCSes to get a feel of the
>>>>> task.
>>>>> For the starter: infer module name from a Fossil's checkout file (it
>>>>> is a sqlite db).
>>>>>
>>>>> Hoe this helps
>>>>>
>>>>> > Best,
>>>>> > Jon
>>>>>
>>>>> --
>>>>> Wojciech S. Czarnecki
>>>>> << ^oo^ >> OHIR-RIPE
>>>>>
>>>> --
>> 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/7beb2ab6-940c-451c-bee6-45ccf73ad8edn%40googlegroups.com
>> <https://groups.google.com/d/msgid/golang-nuts/7beb2ab6-940c-451c-bee6-45ccf73ad8edn%40googlegroups.com?utm_medium=email_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/CADScuBTfsYurSa9KXzNerEhH2XsJZJ1MNzTmAkZSCNLO_Qu1jQ%40mail.gmail.com.

Re: [go-nuts] proposal: infer module name via version control when running `go mod init`

[Jon Calhoun]

I suspect that the VCS path gives nearly the same level of confidence in 
practice. My personal experience shows that it is pretty rare for the two 
not to line up, and when it does the developer made a conscious decision to 
do so and knows to work around it.

I'm also not suggesting that we remove existing behavior. go mod init  is still valid so we don't lose robustness there.


On Wednesday, May 12, 2021 at 10:42:29 AM UTC-4 Bryan C. Mills wrote:

> go mod init should only infer a module path when it can be certain that 
> path is correct.
>
> For packages already stored in GOPATH/src, it knows the correct path with 
> high confidence: the path relative to GOPATH/src is the path by which the 
> packages in the module are imported when in GOPATH mode, so it is safe to 
> assume the same path in module mode.
>
> On the other hand, a module hosted at a particular VCS path can be served 
> through an arbitrarily different path using go-import 
> <https://golang.org/ref/mod#vcs-find> metadata 
> <https://golang.org/ref/mod#vcs-find>, and it could also be a private 
> fork intended for use only with a replace directive 
> <https://golang.org/ref/mod#go-mod-file-replace> (or intended to 
> temporarily host a change while an upstream PR is outstanding). So we 
> cannot assume that the VCS path necessarily corresponds to the module path 
> — it seems more robust to ask the user to supply the intended path 
> explicitly.
>
> On Wednesday, May 12, 2021 at 9:25:48 AM UTC-4 jonca...@gmail.com wrote:
>
>> After more thought, the proposal should be altered to only support git in 
>> the first pass. It would cover a majority of users, wouldn't affect the 
>> experience in other VCS, and would simplify the initial implementation.
>>
>> Doing every VCS at once would require someone learning how every VCS 
>> defines the default remote repository (if it even does), and building off 
>> that. It would be better to do each individually and let someone familiar 
>> with each VCS take charge of that specific PR using existing VCS 
>> implementations as a pattern to follow.
>> On Wednesday, May 12, 2021 at 7:28:11 AM UTC-4 ohir wrote:
>>
>>> Dnia 2021-05-11, o godz. 11:14:24 
>>> Jon Calhoun  napisał(a): 
>>>
>>> > it saves me a handful of keystrokes at best - so I understand if it 
>>> doesn't seem 
>>> > worth the effort. 
>>>
>>> Right. 
>>>
>>> > It feels close enough to the current behavior to be a good addition 
>>>
>>> Gopath is retiring soon. Anyway, Someone needs to do many more 
>>> keystrokes 
>>> to int repository anyway. 
>>>
>>> > , but I admittedly haven't explored how easy/hard it would be to 
>>> implement. 
>>>
>>> Look at the list of currently supported VCSes to get a feel of the task. 
>>> For the starter: infer module name from a Fossil's checkout file (it is 
>>> a sqlite db). 
>>>
>>> Hoe this helps 
>>>
>>> > Best, 
>>> > Jon 
>>>
>>> -- 
>>> Wojciech S. Czarnecki 
>>> << ^oo^ >> OHIR-RIPE 
>>>
>>

-- 
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/7beb2ab6-940c-451c-bee6-45ccf73ad8edn%40googlegroups.com.

Re: [go-nuts] proposal: infer module name via version control when running `go mod init`

[Jon Calhoun]

After more thought, the proposal should be altered to only support git in 
the first pass. It would cover a majority of users, wouldn't affect the 
experience in other VCS, and would simplify the initial implementation.

Doing every VCS at once would require someone learning how every VCS 
defines the default remote repository (if it even does), and building off 
that. It would be better to do each individually and let someone familiar 
with each VCS take charge of that specific PR using existing VCS 
implementations as a pattern to follow.
On Wednesday, May 12, 2021 at 7:28:11 AM UTC-4 ohir wrote:

> Dnia 2021-05-11, o godz. 11:14:24
> Jon Calhoun  napisał(a):
>
> > it saves me a handful of keystrokes at best - so I understand if it 
> doesn't seem
> > worth the effort.
>
> Right.
>
> > It feels close enough to the current behavior to be a good addition
>
> Gopath is retiring soon. Anyway, Someone needs to do many more keystrokes
> to int repository anyway. 
>
> > , but I admittedly haven't explored how easy/hard it would be to 
> implement.
>
> Look at the list of currently supported VCSes to get a feel of the task.
> For the starter: infer module name from a Fossil's checkout file (it is a 
> sqlite db).
>
> Hoe this helps
>
> > Best,
> > Jon
>
> -- 
> Wojciech S. Czarnecki
> << ^oo^ >> OHIR-RIPE
>

-- 
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/132f8177-26ff-47c3-ab0a-1502db42fbf3n%40googlegroups.com.

[go-nuts] proposal: infer module name via version control when running `go mod init`

[Jon Calhoun]

Hi everyone,

Posting this here to get some general feedback before consuming anyone's 
time with a proposal on Github.

The current behavior in the Go tooling is to infer the module name when 
running "go mod init" (without a name) inside of 
$GOPATH/src/github.com/username/repo. Here is an example:

$ cd $GOPATH/src/github.com/joncalhoun/demo
$ go mod init # This creates a go.mod file

# go.mod file generated
module github.com/joncalhoun/demo

go 1.16

I am proposing that the tooling be updated to also infer this from version 
control if present. Using git as an example:

# not in $GOPATH
$ git remote -v
origin g...@github.com:joncalhoun/demo.git (fetch)
origin g...@github.com:joncalhoun/demo.git (push)

go mod init # This creates a go.mod file derived from origin

# go.mod file generated
module github.com/joncalhoun/demo

go 1.16


There are probably some edge cases to consider, like multiple VCS being 
present. In any ambiguous case I propose we stick to the default behavior 
of an error message.

The need for this is pretty minor - it saves me a handful of keystrokes at 
best - so I understand if it doesn't seem worth the effort. It feels close 
enough to the current behavior to be a good addition, but I admittedly 
haven't explored how easy/hard it would be to implement. 

Best,
Jon

-- 
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/83833bc0-3e8a-4c42-b523-2d4e222d2b06n%40googlegroups.com.

Re: [go-nuts] Go += Package Versioning

[Jon Calhoun]

Not ideal, but you *could* release a new major version where the "breaking"
change is the import path change. Eg if you are on v3 now, make a v4 folder
and the upgrade to v4 process would involve updating import paths. I
wouldn't do this right away since vgo is just a prototype and could change
to handle this situation better, but it is an option.


On Fri, Feb 23, 2018 at 10:00 AM, Nic Pottier  wrote:

> On Fri, Feb 23, 2018 at 7:59 AM, roger peppe  wrote:
> > As Russ pointed out to me, you can work around that by using a
> > 0.0.0-2101234543-4f34f456eeefdcba version in your go.mod require
> > section. If you've got that, it ignores the version tags.
>
> Right, that works for clients of the library (and I did manage to get
> my projects working with that and it now feels magical) but authors of
> modules above v1 are posed with a bit of a quandary as to how to give
> their users a nice vgo version without breaking current users on plain
> go.
>
> From Russ's latest post I think the answer is you put a v3 subdir in
> your repo with a copy of the code, add a mod.go and update both the
> root and v3 until vgo becomes adopted everywhere.
>
> -Nic
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/golang-nuts/jFPz5yZCPcQ/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Go += Package Versioning

[Jon Calhoun]

Would you be willing to create an example illustrating how a versioned 
package should look with major version changes? You have great examples for 
the minor/patch changes, but I don't see any concrete examples for a major 
version bump.

On Tuesday, February 20, 2018 at 12:20:54 PM UTC-5, Russ Cox wrote:
>
> Hi everyone,
>
> I have a new blog post you might be interested in.
> https://research.swtch.com/vgo.
>
> I'll try to watch this thread to answer any questions.
>
> Best,
> Russ
>
>
>
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Resources to learn Go as a first programming language?

[Jon Calhoun]

You can also check out Caleb Doxseys free ebook - 
https://www.golang-book.com/books/intro

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Who are the https://gophers.slack.com/ admins?

[Jon Calhoun]

I believe the people over at https://golangbridge.org/ are responsible for 
the Slack as well, so I would contact them.




On Monday, November 13, 2017 at 1:41:13 PM UTC-5, Vlad Didenko wrote:
>
> My phone got stolen, so I am locked out of the https://gophers.slack.com/ 
> 2FA.
>
> Slack tells to ask project admins to temporarily reset @FA on the account, 
> but I found no way to find who are the admins for the gophers workspace. 
> Anyone knows?
>
>
> 
>
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Newbie How to read unmarshall a varient struct in Json

[Jon Calhoun]

See the last section of this article where it talks about generics - 
https://blog.gopheracademy.com/advent-2016/advanced-encoding-decoding/

It isn't exactly what you are doing but the same idea should work in your use 
case. The encoding/decoding code becomes longer but it makes using the data 
simpler. 

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Json-ifying map[bson.ObjectId] is not as expected

[Jon Calhoun]

The first bson.ObjectID that you show isn't actually what is stored in the 
object, but rather it is hex value of the object ID that is acquired by 
calling 

id.Hex()

It looks like that isn't what gets printed out when marshaling your map, 
and instead the IDs are printed out as whatever the raw value stored in a 
bson.ObjectID are.

You could update your code to instead store a string for the map where the 
key is `id.Hex()` instead of just the id. Eg:

type Stats struct {
A bson.ObjectId `json:"a,omitempty" bson:"a,omitempty"`
B map[string]CustomType `json:"b,omitempty" bson:"b,omitempty"`
}

type CustomType struct {
Name string
}

func main() {
id := bson.NewObjectId()
stats := Stats{
A: id,
B: map[string]CustomType{
id.Hex(): CustomType{"jon"},
},
}
bytes, err := json.Marshal(stats)
if err != nil {
panic(err)
}
fmt.Println(string(bytes))
}


If you really want this data to be a `map[bson.ObjectID]CustomType` you 
could likely do this with a custom type like so

type BsonMap map[bson.ObjectID]CustomType

And then implementing the https://golang.org/pkg/encoding/json/#Unmarshaler 
and https://golang.org/pkg/encoding/json/#Marshaler interfaces. 

Hope that helps!
Jon


On Wednesday, December 21, 2016 at 1:40:33 PM UTC-5, Vincent Jouglard wrote:
>
> Hi,
>
> I am sending a map of elements indexed by a bson.ObjecId(), coming from 
> the bdd.
>
>
> type Stats struct {
>  A bson.ObjectId `json:"a,omitempty" bson:"a,omitempty"`
>  B map[bson.ObjectId]CustomType   `json:"b,omitempty" bson:"b,omitempty"`
> }
>
>
> // t is of type Stats 
> if err = c.WriteJSON(t); err != nil { // c is of type *Conn from mux 
> websocket, and this is where magic happens
>  fmt.Println("write:", err) // Nothing is triggered here
>  break
> }
>
>
> The result is not as expected :
>
>
>"57ffdff9687a95381c5831d3" // this is A
>B:{,…} 
>W6�0���}: // this is the index of the first element of B
>W6�3���
>
>   
> The bson.ObjectId object A is healthy as expected, while the indexes of 
> the elements of B are quite unreadable.
> I have tried WriteJson and (Marshal + WriteMessage) - both WriteJson and 
> WriteMessage are wrappers of the native methods, from gorilla/mux -
>
> Do you know of anything special marshaling map[bson.ObjectId] ?
>
> Thanks for your help,
>
>
>
>1. 
>   
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: multiple html templates

[Jon Calhoun]

What you are doing seems pretty normal. You could technically parse each 
HTML file into it's own template and then just use

  
baseTemplate.Execute(...)

and 

dataTemplate.Execute(...) 

in your code instead, but I really doubt what you are doing has a 
noticeable performance hit (if it even has one).


On Sunday, November 27, 2016 at 3:03:16 PM UTC-5, keit...@gmail.com wrote:
>
> Hello,
>
> I am building a site which will have the following pages, "/" (home), 
> "/about", and "/data" which will show some data using DataTables 
> . 
>
> "/", "/about" will be simple so I am using templates/base.html but for 
> /data I would still like to use tempaltes/data.html because I need to load 
> DataTables code. To do this I am creating a seperate handler and I am not 
> sure if this is the right way to do it.
>
> So, is a seperate handler needed? and how inefficient is it?
>
>
>
>
> var templates = template.Must(template.ParseFiles("templates/base.html", 
> "templates/data.html")) 
>
> func handler(w http.ResponseWriter, r *http.Request) { 
>   
> log.Printf(r.URL.Path[1:]) 
> myVars := 
> Variables{"Main", "My Heading #1"} 
> err := 
> templates.ExecuteTemplate(w, "base.html", myVars)   
> 
>   if err != nil { 
>   
> http.Error(w, err.Error(), http.StatusInternalServerError) 
>   
> return 
> }
> }
>
>  
> func staticHandler(w http.ResponseWriter, r *http.Request) {   
> 
> 
> http.ServeFile(w, r, r.URL.Path[1:])   
> 
> 
> } 
> 
>  
>   
> 
>  
> func dataHandler(w http.ResponseWriter, r *http.Request) { 
> 
> 
> myVars := Variables{"About", "About page"} 
> 
> 
> err := templates.ExecuteTemplate(w, "data.html", myVars)   
> 
> 
> if err != nil {   
> 
>  
> http.Error(w, err.Error(), http.StatusInternalServerError) 
> 
> 
> return 
> 
> 
> } 
> 
>  
> } 
> 
>  
>  
> func main() { 
> 
>  
> fmt.Printf("ok\n") 
> 
> 
> 

[go-nuts] Re: Deleting the /r/golang subreddit

[Jon Calhoun]

A few things I think are worth considering:

a. If r/golang is deleted, what is going to stop someone else from creating 
another go oriented subreddit? And if this happens, will people like bradfitz 
having less control be a good thing?

Sure, a new subreddit might not grow as quickly without any official support, 
but I doubt it will just go away and never reappear in some shape or form, and 
I think giving up the moderation to any random person who creates the subreddit 
is a bad idea. 


b. Forums and reddit serve a different purpose for me. Something like 
https://golangnews.com/ could replace what I get out of reddit, but a forum 
won't. I use reddit becuase it is a great place to discover articles that 
others are voting on in some capacity to help filter the bad from the good. I 
also appreciate it as an author as a way to help share my own writing.

The reddit community might be toxic in a lot of ways, but I suspect that 
getting 25k+ people to create an account on a new service is going to be hard, 
especially if that new service has the risk of similar issues.

The only way I see an alternative option working is if it is officially 
maintained by the Go team in some way, and I really would dislike seeing 
r/golang shut down without a viable alternative.



Having said all of that, I am not opposed to a change, and I think a more 
viable path to making a change would be:

1. Don't delete the subreddit, but stop officially supporting it (ie delete 
links to it on github or wherever else)
2. Come up with a viable & trustworthy alternative and release it
3. Start pointing people to the alternative, including in the subreddit 
(stickied post?), but don't delete the subreddit.  


Just my 2 cents.

- Jon

-- 
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.
For more options, visit https://groups.google.com/d/optout.