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

[Sam Whited]

On Sat, Feb 24, 2018, at 21:44, Sean Russell wrote:
> I'm working on adding support for Bitbucket, per your comment in #23950 
> .  I'm struggling a bit with 
> executing the tests in x/vgo -- should I expect vgo test to work?  I feel 
> like I'm missing something obvious.

FYI, there is an active CL for this here: https://golang.org/cl/95578

—Sam

-- 
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

[Maxim Ivanov]

I am replying mostly to https://resea rch.swtch.com/vgo-import article.

It is proposed that "moauth" author should do double work, even if his code 
works absolutely fine with either verion of oauth. This viral effect will 
be causing chain reaction and a lot of people will be creating unnecessary 
major semver releases. "moauth" author doesn't need to do anything, but 
once vgo is out , he'll be receiving requests from "aws" to do theese 
releases and "aws" itself will be blocked on somebody else without a way to 
move forward with "oauth/v2".

It will also cause combinatorial explosion, just imagine if "moauth" 
depends on "oauth" and "samlauth", would it need to release 4 major semver 
versions for all combinations of dependencies visible in API? Looks like it 
is inevitable, as users of "moauth" can decide to use types from either 
version of "oauth" and "samlauth".

IMHO right solution vgo should promote is to apply semver trick described 
here: https://github.com/dtolnay/semver-trick/blob/master/README.md . In a 
nutshell it suggests that "oauth/v1" imports "oauth/v2" and type aliases 
all common types visible in API. Then "moauth" doesn't need a new semver 
release at all, it stops being viral and whole dependency chain becomes 
much much simpler.

Go community is going to to do pretty much whatever Russ tells them with 
imminent vgo release, if smever trick indeed solves this viral problem, it 
should be encouraged from day 0.

-- 
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

[Spencer Nelson]

I'd like to better understand how multiple-module repositories work if 
tagged commits are used for minor and patch versioning.

My understanding is that major version increments are controlled with 
import paths, while minor and patch version increments are controlled with 
commit tags.

Is it possible for me to have different minor/patch versions for different 
modules in one repository? For example, suppose I have this:

github.com/my/thing/go.mod
github.com/my/thing/blue/go.mod

And suppose my current commit is tagged with v1.0.0.

Now I fix a bug in github.com/my/thing/blue. How do I indicate that 
github.com/my/thing/blue is at v1.0.1 without changing 
github.com/my/thing's version?

On Tuesday, February 20, 2018 at 9:20:54 AM UTC-8, 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] Go += Package Versioning

[ivanov . maxim]

The proposed rules around semver and minimal version selection address 
> every pain point I've had so far, by aligning available authority with the 
> responsibility of the library authors: tell me what versions definitely 
> will *not* work, and I'll take it from there.
>
>
Maybe I miss something, but it is exactly what vgo doesn't let library 
authors to do. Sometimes "too new" is definitely not going to work for 
multiple reasons, but there is no way to convey that knowledge to library 
users.

-- 
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

[Sean Russell]

Russ,

I'm working on adding support for Bitbucket, per your comment in #23950 
.  I'm struggling a bit with 
executing the tests in x/vgo -- should I expect vgo test to work?  I feel 
like I'm missing something obvious.

I added unit tests first and they're failing (as expected) but not for the 
reasons I'd expect:

➜  vgo git:(master) ✗ vgo test ./vendor/cmd/go/internal/modfetch/   
   
vgo: import "github.com/serussell/vgo/vendor/cmd/go/internal/modfetch" ->
import "cmd/go/internal/modconv" [/usr/local/go/src/cmd/go/internal/
modconv]: open /usr/local/go/src/cmd/go/internal/modconv: no such file or 
directory

Many similar messages follow this. Why is it looking in GOROOT?  The 
project directory structure still follows the legacy 
$GOPATH/src/github/serussell/vgo pattern.

I'm hacking on fetch.go, but I'd feel more comfortable if I could execute 
the unit tests.

Thanks,

--- SER

-- 
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

[bits128]

Hi Russ, I had a question about this:

> We expect that most developers will prefer to follow the usual “major 
branch” convention, in which different major versions live in different 
branches. In this case, the root directory in a v2 branch would have a 
go.mod indicating v2, like this:

It seems like there's subdirectories and this major branch convention that 
are both supported by vgo. In my anecdotal experience no repositories 
follow this convention in Go or other languages (can't actually think of a 
single one other than the ones forced to by gopkg.in which seems relatively 
unused these days). Master branch is whatever latest is and has v2.3.4 tags 
in it's history. Tags exist to separate everything (not just minor 
versions). If it's necessary to patch an old version, a branch is 
temporarily created off the last v1 tag, commits pushed, a new tag pushed, 
and the branch summarily deleted. There is no branch for versions, it's 
just current master/dev/feature branches + version tags.

Having said that, I've tested the above described workflow with vgo (just 
having tags that say v2.0.0, v2.0.1 and no branches) and it does seem to 
work (though as an aside it is pretty confusing/annoying to have to change 
the require statement to say both /v2 as well as v2.0.0 when you upgrade 
the dependency in go.mod, not sure why that's required). So my question is: 
Although this works now, is it intended? As it doesn't seem as thoroughly 
described as the other two workflows in the blog, and I want to ensure that 
working without a v2/v3... branch is not accidental functionality that will 
disappear since as I explained above I've never seen this (or the other) 
described workflow in the post to be massively adopted by anyone 
(especially outside the Go community).

Of course my argument is coming down to preference and anecdotes, so I'd be 
willing to do some repo-scraping to prove this across all languages if 
needed. So far I've really liked the proposal posts and am generally on 
board with the changes, will continue to follow along and play with vgo.

Thanks for all your efforts.

Aaron

On Tuesday, February 20, 2018 at 9:20:54 AM UTC-8, 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] Appreciating Go

[Bakul Shah]

r := os.Open(filename)
if isError(r) { return r.(error) }
f := r.(*os.File) // or better: var f *os.File; f = r

Error checking being a common pattern, isError() can be added as a builtin
or trivially in errors pkg. Likely the enclosing function also returns an error
so the return in the second line above can be just return r but with the
current product type approach you’d have return nil, err.

You are only looking at code after returning. Code within a function benefits
more (gets simplified).

func f(s string) (int|error) { // instead of (int,error)
  ...
  return err // instead of return 0,err
  ...
  return 1 // instead of return 1,nil
  // and return n, err case disappears

Having to return an extra thing that gets discarded right away is annoying.
Early on this was a common mistake for me. We are used to it now but the
current idiom came about because of a lack of sum types. People can use
object{} as a return type today but that more or less defeats type checking
which may be why returning an extra thing was perhaps seen as acceptable.
So yes, I do think sum types benefit here. May be not enough for people to
want a change but net benefit nonetheless.

The bigger benefit is their use where people currently end up using object{}
or product type. With sum types you get better documentation and checking.
If you think of sum types as just restricted object{} types, they are simple to 
explain and implement. Simpler than what you guys were discussing on issue
19412 thread. I will add a comment there.

On Feb 24, 2018, at 12:03 PM, roger peppe  wrote:

>> I once counted there were about 8000 uses of ,error as
>> return types for functions in $GOROOT/src which could benefit
>> from sum types.
> 
> I'm not entirely convinced that sum types are a net win as a
> substitute for (T, error) return values.
> 
> Where currently we have:
> 
>  f, err := os.Open(filename)
>  if err != nil {
>  return err
>  }
>  // use f
> 
> we'd have to do something like:
> 
>  fOrError := os.Open(filename)
>  if err, ok := fOrError.(error); ok {
>   // ... but what happens if we want to return a distinct
>   // value that implements error?
>   return err
>  }
>  f := fOrError.(*os.File)
>  // use f
> 
> or perhaps:
> 
>  var f *os.File
>  switch fOrError := os.Open(filename).(type) {
>  case *os.File:
>  f = fOrError
>  case error:
>  return fOrError
>  }
>  // use f
> 
> or even, defensively (perhaps os.Open's type might change to admit
> more possibilities:
> 
>  var f *os.File
>  switch fOrError := os.Open(filename).(type) {
>  case *os.File:
>  f = fOrError
>  case error:
>  return fOrError
>  default:
>  panic("unexpected type %T returned from os.Open", fOrError)
>  // or return error
>  }
>  // use f
> 
> I don't know about you, but I wouldn't consider any of those a
> particular improvement on the current idiom. They're all more verbose
> and not actually that much more type-safe.
> 
> That doesn't mean that I don't think sum types are a decent idea, but
> just that I'm not sure that they're as clear a win for this (a
> commonly cited use case) as one might think.
> 
>  cheers,
>rog.
> 
> 
>> On 24 February 2018 at 01:23, Bakul Shah  wrote:
>>> On Thu, 22 Feb 2018 12:55:01 + Jesper Louis Andersen 
>>>  wrote:
>>> 
>>> For sums, in Go, I have to return a pair,
>>> 
>>> x, err := someOperation(..)
>>> 
>>> but this is slightly inconsistent, insofar I can return "nil, nil", which
>>> might not be a valid value, or I can return "3, Error(..)" but in that case
>>> the 3 is not to be used. Only one "side" is valid at a given point in time.
>>> If you have sum-types in the usual sense, you can define something along
>>> the lines of (OCaml follows):
>>> 
>>> type ('a, 'b) result = Ok of 'a | Error of 'b
>> 
>> I once worked out some details of adding sum types to Go and I
>> think it is quite doable and easy to implement. For example,
>> 
>>func f(i int) float64|error {
>>if i == 0 { return errors.New("not zero") }
>>return 1./float64(i)
>>}
>> 
>> As in OCaml "|" is used for sum types and it binds less
>> tightly than existing type "expressions".
>> 
>>> And then you can discriminate on this value via pattern matching
>>> 
>>> match res with
>>> | Ok value -> ...
>>> | Error err -> ...
>> 
>> Not quite the same but something similar is doable with
>> type switch.
>> 
>>res := f(j)
>>switch res.(type) {
>>case error: ...
>>case string: ...
>>}
>> 
>> This use is identical with f returning interface{} (even the f
>> body remains exactly the same).  This makes sense since
>> interface{} is in a sense the sum of all other types.
>> 
>> But by allowing sum type, we can do better checking within f
>> (e.g. return "string" will fail to 

Re: [go-nuts] Appreciating Go

[roger peppe]

> I once counted there were about 8000 uses of ,error as
> return types for functions in $GOROOT/src which could benefit
> from sum types.

I'm not entirely convinced that sum types are a net win as a
substitute for (T, error) return values.

Where currently we have:

  f, err := os.Open(filename)
  if err != nil {
  return err
  }
  // use f

we'd have to do something like:

  fOrError := os.Open(filename)
  if err, ok := fOrError.(error); ok {
   // ... but what happens if we want to return a distinct
   // value that implements error?
   return err
  }
  f := fOrError.(*os.File)
  // use f

or perhaps:

  var f *os.File
  switch fOrError := os.Open(filename).(type) {
  case *os.File:
  f = fOrError
  case error:
  return fOrError
  }
  // use f

or even, defensively (perhaps os.Open's type might change to admit
more possibilities:

  var f *os.File
  switch fOrError := os.Open(filename).(type) {
  case *os.File:
  f = fOrError
  case error:
  return fOrError
  default:
  panic("unexpected type %T returned from os.Open", fOrError)
  // or return error
  }
  // use f

I don't know about you, but I wouldn't consider any of those a
particular improvement on the current idiom. They're all more verbose
and not actually that much more type-safe.

That doesn't mean that I don't think sum types are a decent idea, but
just that I'm not sure that they're as clear a win for this (a
commonly cited use case) as one might think.

  cheers,
rog.


On 24 February 2018 at 01:23, Bakul Shah  wrote:
> On Thu, 22 Feb 2018 12:55:01 + Jesper Louis Andersen 
>  wrote:
>>
>> For sums, in Go, I have to return a pair,
>>
>> x, err := someOperation(..)
>>
>> but this is slightly inconsistent, insofar I can return "nil, nil", which
>> might not be a valid value, or I can return "3, Error(..)" but in that case
>> the 3 is not to be used. Only one "side" is valid at a given point in time.
>> If you have sum-types in the usual sense, you can define something along
>> the lines of (OCaml follows):
>>
>> type ('a, 'b) result = Ok of 'a | Error of 'b
>
> I once worked out some details of adding sum types to Go and I
> think it is quite doable and easy to implement. For example,
>
> func f(i int) float64|error {
> if i == 0 { return errors.New("not zero") }
> return 1./float64(i)
> }
>
> As in OCaml "|" is used for sum types and it binds less
> tightly than existing type "expressions".
>
>> And then you can discriminate on this value via pattern matching
>>
>> match res with
>> | Ok value -> ...
>> | Error err -> ...
>
> Not quite the same but something similar is doable with
> type switch.
>
> res := f(j)
> switch res.(type) {
> case error: ...
> case string: ...
> }
>
> This use is identical with f returning interface{} (even the f
> body remains exactly the same).  This makes sense since
> interface{} is in a sense the sum of all other types.
>
> But by allowing sum type, we can do better checking within f
> (e.g. return "string" will fail to compile). And by using a
> sum type instead of a product type to return a value or error
> also makes the code clearer.
>
> I once counted there were about 8000 uses of ,error as
> return types for functions in $GOROOT/src which could benefit
> from sum types. Now there seem to be about 4253 instances
> (found using a crude regexp).
>
> I think I worked out the semantics of T1|T2 where T1 and T2
> are both interface types themselves. It all seem to fit
> together, at least on paper! I need to find my notes
>
>> The other matching construction is a switch-statement, but such a statement
>> doesn't allow for matching deeply into an AST structure, which a
>> traditional pattern matcher does.
>
> Deeper matching also binds names to matched parts. e.g.
>
> sumsqr [] = 0
> sumsqr (x:xs) = x*x + sumsqr xs
>
> This sort of binding may be difficult to shoehorn into Go.
> There may be no real benefit of binding head, tail of a slide
> but consider an AST. If you are already cracking it open for
> matching it with a pattern, you may as well bind variables to
> interesting parts.
>
> match stmt {
> case If1stmt(test:, thenstmt:): ...
> case If2stmt(test:, thenstmt:, elsestmt:): ...
> ...
> }
>
> Hard to come up with an intuitive syntax here.  Also probably
> impossible  to add func level patterns.
>
>> Coincidentally, given sum-types, you can write a regexp matching engine in
>> very few lines of code. See Bob Harper's "Programming in Standard ML" [2]
>> for example; it is the introductory example to get a feel for the language.
>> The solution uses sum types to define the AST for regular expressions, and
>> then uses pattern matching to build a matcher on regular expressions. I
>> can't remember how far Bob 

Re: [go-nuts] Re: Experience report on coming to Go from a C perspective

[Egon]

Few additional possible solutions:

1. use something similar to https://github.com/awalterschulze/goderive 
create appropriate func.
2. some IDE / tool should be able to figure these refactorings out... or at 
least find the places that need to be changed. Changing a field or method 
name is quite similar to this problem so I cannot see why an editor 
wouldn't be able to do it.

*As for the proposed solution "make(Set.members)", I like it :)*

On Thursday, 22 February 2018 23:58:25 UTC+2, Devon H. O'Dell wrote:
>
> Thanks for pointing this out; I wasn't aware of this new syntax. I 
> think this gets to about halfway of what I'd hope for. That said, I'd 
> really like to avoid needing to jump through the hoop of indirection 
> for this. I occasionally find it hard to recognize what the type of a 
> thing is due to heavy use of type inference, so I'd hope for something 
> that doesn't require me to do additional backtracking to figure out 
> what the real underlying type is. 
>
> 2018-02-22 12:31 GMT-08:00  : 
> > Have you considered using the new type alias feature introduced in 1.9? 
> Line 
> > so: 
> > 
> > https://play.golang.org/p/6HK8qcuh9UU 
> > 
> > This would allow you to change the type of the map in a singe place (the 
> > type alias) and all the {} or make would adapt appropriately. 
> > Disclaimer: I am not espousing this style, just pointing out that it is 
> > possible. 
> > 
> > 
> > 
> > On Thursday, February 22, 2018 at 3:03:13 PM UTC-5, Devon H. O'Dell 
> wrote: 
> >> 
> >> Hi all, 
> >> 
> >> It's been some time since I really contributed much of anything to the 
> >> project (sorry!), but after 8 years, I'm finally writing Go outside of 
> >> the project itself (and outside of porting efforts). I was lamenting 
> >> to some coworkers about the lack of a comparable feature to C's 
> >> "malloc idiom" and they suggested I write an experience report on it. 
> >> I wrote the bulk of the article a month ago, but finally put in some 
> >> finishing touches and published. 
> >> 
> >> For whatever it's worth (probably not much): 
> >> https://9vx.org/post/a-malloc-idiom-in-go/ 
> >> 
> >> --dho 
> > 
> > -- 
> > 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 . 
> > 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: vgo with package path without dot

[flicaflow]

I'm not saying it shouldn't work as you try to do it. I thing vgo is a very 
early prototype many corner cases seem to be unsolved. Your problem arises 
because the old mechanism (GOPATH) is not there anymore. 
I actually think that your replace workaround should work, so maybe you 
should file an issue. 
If this is good practice is a different topic.

I would rather restructure my source a bit to make it work (e.g. make mylib 
a child of myapp) than requiring some proxy infrastructure. 


Am Freitag, 23. Februar 2018 11:15:54 UTC+1 schrieb wilk:
>
> Hi, 
>
> I work with GOPATH per project. 
>
> Then I use to give them a one word path directly under src: 
>
> $GOPATH/src/myapp 
>
> But I found that it doesn't work with vgo. It looks at 
> /usr/local/go/src/ instead of my GOPATH. 
> The same when i use replace with a clone of a libs. 
>
> If there is a dot in the package name it works 
>
> $GOPATH/src/my.domain/myapp/ 
>
> Should i submit an issue or shoud i forget quickly this bad practice ? 
>
> -- 
> William 
>
>

-- 
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 Programming Language Course

[bnixon67]

As an alternate to Linux VMs, is it possible to install the Windows 
Subsystem  on 
the Windows 10 lab machines?

What IDE, if any, do you plan to use and how complex are the programs? Do 
you need to worry about C integration, cross-compilation, or other 
complexity? If not, some of the concerns in this thread are eliminated or 
minimized.

Personally (but I'm "old school"), I think it is good for students to learn 
about the underlying environment, so learning Linux, command-line 
compilation, etc will make them better, well-rounded developers, especially 
for Go, which is focused more on the back-end systems programming. It's 
frustrating in the business world where we may have a great developer, but 
they don't understand the underlying computing environment and aren't as 
effective when more complex issues come up with code verses infrastructure 
interaction. I think a "converged" developer is a good thing.

On Wednesday, February 21, 2018 at 8:25:38 AM UTC-6, Dick Seabrook wrote:

> I'm putting together a 3-credit introduction to the Go programming 
> language at 
> the community college level. I will create (as a minimum) syllabus, 
> outline, 
> lecture notes, handouts, assignments, projects, quizzes and final exam. I 
> will
> probably start with the Donovan & Kernighan A-W 2015 text.
> Prerequisite: familiarity with personal computers and at least one 
> programming
> language, preferably C.
> I'd like to set it up in a shared Linux environment although I'll be 
> teaching
> exclusively in Windows 10 labs. Fortunately we've got a large Linux VM on 
> campus
> so the Linux base is do-able, however is there any value in teaching Go on
> Windows 10 natively?
>
> Any thoughts or suggestions?
> Thanks,
> Dick S.
>
>

-- 
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: vgo with package path without dot

[wilk]

On 24-02-2018, flicaf...@gmail.com wrote:
> --=_Part_9366_348433021.1519468400573
> Content-Type: multipart/alternative; 
>   boundary="=_Part_9367_868487623.1519468400573"
>
> --=_Part_9367_868487623.1519468400573
> Content-Type: text/plain; charset="UTF-8"
>
> Vgo implements a package manager which is suppose to download dependencies 
> from some remote host.

I tried this as a workaround :

require "mylib" v0.1.0
replace "mylib" v0.1.0 => "../mylib"

But it doesn't work either.

I see your point, you're right, it's evident. I just don't use that 
build also fetch !

Anyway the more I think the more I see that it will give more 
possibilities, with vgo proxy and so on...

I created an issue to put it in the FAQ maybe.

https://github.com/golang/go/issues/24100

thanks

-- 
William

-- 
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: math integer sizes

[Stefan Nilsson]

I don't know why it's not part of the standard library, but here is a piece 
of code that does the job. (It's written in a slightly roundabout way to 
make sure that the constants are untyped.)


const BitsPerWord = 32 << (^uint(0) >> 63) // either 32 or 64

const (
MaxInt  = 1<<(BitsPerWord-1) - 1 // either 1<<31 - 1 or 1<<63 - 1
MinInt  = -MaxInt - 1// either -1 << 31 or -1 << 63
MaxUint = 1<
> I see that the math/bits package has a UintSize constant, and math has 
> Max types. Why doesn't math have MaxInt and MaxUint?
>
> Yes, I know that these are derivative by themselves, but can they be 
> included in the standard library without breaking the Go Compatibility 
> promise?
>

-- 
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: vgo with package path without dot

[wilk]

On 24-02-2018, Amnon Baron Cohen wrote:
> --=_Part_9094_478136164.1519461749739
> Content-Type: multipart/alternative; 
>   boundary="=_Part_9095_482511421.1519461749739"
>
> --=_Part_9095_482511421.1519461749739
> Content-Type: text/plain; charset="UTF-8"
>
>
>
> On Friday, 23 February 2018 
>>
>>
>> I work with GOPATH per project. 
>>
>> Then I use to give them a one word path directly under src: 
>>
>> $GOPATH/src/myapp 
>>
>>
> Go is a highly opinionated language assumes that you lay out your code as 
> described in https://golang.org/doc/code.html
> If you decide to do things differently (by having 'simpler' paths 
> which do not correspond to the VCS location of your code on the net), 
> then you end up having to fight the go tools, rather than have them 
> work for you.
>

I don't think it's not recommended :

https://golang.org/doc/install#testing

Next, make the directory src/hello inside your workspace, and in that 
directory create a file named hello.go

$ cd $HOME/go/src/hello
$ go build

https://blog.golang.org/organizing-go-code
If you don't use a hosted source repository, choose some unique prefix 
such as a domain, company, or project name. As an example, the import 
path of all Google's internal Go code starts with the string "google".


-- 
William

-- 
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: vgo with package path without dot

[flicaflow]

Vgo implements a package manager which is suppose to download dependencies 
from some remote host.
It determines where to fetch the code by looking at the import path of the 
dependency.
Hence All dependencies which are managed with the new vgo mechanism musst 
follow this import path convention.
Other dependencies are either the std lib, I guess this is a special case, 
or are packages which are below your project go.mod. 
As I understand it vgo does not respect the GOPATH any more, so it might 
not find packages which are just next to your package in the GOPATH.

As for your package "myapp" it should be sufficient to give the module a 
appropriate name in the go.mod file:

module "my.domain/myapp"

However this would make it not usable as a dependency in other packages 
with vgo.




Am Freitag, 23. Februar 2018 11:15:54 UTC+1 schrieb wilk:
>
> Hi, 
>
> I work with GOPATH per project. 
>
> Then I use to give them a one word path directly under src: 
>
> $GOPATH/src/myapp 
>
> But I found that it doesn't work with vgo. It looks at 
> /usr/local/go/src/ instead of my GOPATH. 
> The same when i use replace with a clone of a libs. 
>
> If there is a dot in the package name it works 
>
> $GOPATH/src/my.domain/myapp/ 
>
> Should i submit an issue or shoud i forget quickly this bad practice ? 
>
> -- 
> William 
>
>

-- 
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: vgo with package path without dot

[Amnon Baron Cohen]

On Friday, 23 February 2018 
>
>
> I work with GOPATH per project. 
>
> Then I use to give them a one word path directly under src: 
>
> $GOPATH/src/myapp 
>
>
Go is a highly opinionated language assumes that you lay out your code as 
described in https://golang.org/doc/code.html
If you decide to do things differently (by having 'simpler' paths which do 
not correspond to the 
VCS location of your code on the net), then you end up having to fight the 
go tools, 
rather than have them work for you.

-- 
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.