Re: [go-nuts] go get + build flag to set version var

2017-05-05 Thread mhhcbon
sorry, mistake,

** My point is not criticize, but the way you describe the *how*
that pipeline should happen IRL.
That desciption seems taken from
controlled environment such as 
- internal company
- oss distro

On Friday, May 5, 2017 at 2:57:44 PM UTC+2, mhh...@gmail.com wrote:
>
> yeah i agree.
>
> But (:/), i think its pipeline issue in the consumption of a go package.
>
> In the same way the language is made to prevent user errors (as much as 
> possible, and its difficult)
> that go get pipeline usage should help in that matter too.
>
> My point is not criticize, but the way you describe the *how*
> that pipeline should happen IRL seems taken from
> controlled environment such as 
> - internal company
> - oss distro
>
> where every users is somehow subordinated to a common decision taker, a 
> commander ;)
>
> Typically inside google you can use such rules and later blame the end dev 
> which did not followed it.
>
> On the internet it is much less possible.
>
> And yes hopefully, so far, only one ticket :)
>
> But scale it by number of package providers * number of package users and 
> you get a mess of repeated questions, 
> no ?
>
>
> On Friday, May 5, 2017 at 2:47:51 PM UTC+2, Jakob Borg wrote:
>>
>> On 5 May 2017, at 14:41, mhh...@gmail.com wrote: 
>> > 
>> > Just to add on this that the fact i provide pre built bin is not 
>> winning against go get, 
>> > 
>> > The repo i took as example is providing, 
>> > https://github.com/mh-cbon/emd/releases 
>> > 
>> > and all possible ways to install it i can provide, 
>> > https://github.com/mh-cbon/emd#install 
>> > 
>> > So yeah i did my best, i loosed. 
>>
>> You don't have *that* many issues opened. :) Here you are probably 
>> targeting developers. They may be somewhat more likely to grab it from 
>> source than others. They can probably also answer the question "what git 
>> hash did you build from?" if that seems relevant. 
>>
>> On issues from other users I can usually get a feeling for whether the 
>> bug is something I expect or something that should not be possible. If the 
>> latter and the build seems suspect, "can you retry this with the latest 
>> official build please?". 
>>
>> But yeah. The source is out there, you can't *prevent* people from 
>> compiling it. (Other than not being go-gettable, which has advantages and 
>> disadvantages.) 
>>
>> //jb
>
>

-- 
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 get + build flag to set version var

2017-05-05 Thread mhhcbon
yeah i agree.

But (:/), i think its pipeline issue in the consumption of a go package.

In the same way the language is made to prevent user errors (as much as 
possible, and its difficult)
that go get pipeline usage should help in that matter too.

My point is not criticize, but the way you describe the *how*
that pipeline should happen IRL seems taken from
controlled environment such as 
- internal company
- oss distro

where every users is somehow subordinated to a common decision taker, a 
commander ;)

Typically inside google you can use such rules and later blame the end dev 
which did not followed it.

On the internet it is much less possible.

And yes hopefully, so far, only one ticket :)

But scale it by number of package providers * number of package users and 
you get a mess of repeated questions, 
no ?


On Friday, May 5, 2017 at 2:47:51 PM UTC+2, Jakob Borg wrote:
>
> On 5 May 2017, at 14:41, mhh...@gmail.com  wrote: 
> > 
> > Just to add on this that the fact i provide pre built bin is not winning 
> against go get, 
> > 
> > The repo i took as example is providing, 
> > https://github.com/mh-cbon/emd/releases 
> > 
> > and all possible ways to install it i can provide, 
> > https://github.com/mh-cbon/emd#install 
> > 
> > So yeah i did my best, i loosed. 
>
> You don't have *that* many issues opened. :) Here you are probably 
> targeting developers. They may be somewhat more likely to grab it from 
> source than others. They can probably also answer the question "what git 
> hash did you build from?" if that seems relevant. 
>
> On issues from other users I can usually get a feeling for whether the bug 
> is something I expect or something that should not be possible. If the 
> latter and the build seems suspect, "can you retry this with the latest 
> official build please?". 
>
> But yeah. The source is out there, you can't *prevent* people from 
> compiling it. (Other than not being go-gettable, which has advantages and 
> disadvantages.) 
>
> //jb

-- 
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 get + build flag to set version var

2017-05-05 Thread Jakob Borg
On 5 May 2017, at 14:41, mhhc...@gmail.com wrote:
> 
> Just to add on this that the fact i provide pre built bin is not winning 
> against go get,
> 
> The repo i took as example is providing,
> https://github.com/mh-cbon/emd/releases
> 
> and all possible ways to install it i can provide,
> https://github.com/mh-cbon/emd#install
> 
> So yeah i did my best, i loosed.

You don't have *that* many issues opened. :) Here you are probably targeting 
developers. They may be somewhat more likely to grab it from source than 
others. They can probably also answer the question "what git hash did you build 
from?" if that seems relevant.

On issues from other users I can usually get a feeling for whether the bug is 
something I expect or something that should not be possible. If the latter and 
the build seems suspect, "can you retry this with the latest official build 
please?".

But yeah. The source is out there, you can't *prevent* people from compiling 
it. (Other than not being go-gettable, which has advantages and disadvantages.)

//jb

-- 
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 get + build flag to set version var

2017-05-05 Thread mhhcbon
Just to add on this that the fact i provide pre built bin is not winning 
against go get,

The repo i took as example is providing,
https://github.com/mh-cbon/emd/releases

and all possible ways to install it i can provide,
https://github.com/mh-cbon/emd#install

So yeah i did my best, i loosed.

On Friday, May 5, 2017 at 2:38:34 PM UTC+2, mhh...@gmail.com wrote:
>
> I totally agree with you and implemented such build pipeline.
>
> But still, the fact is i have such situation, 
> I might run after each and every ticket like this,
> that does not seem a run i can win ;)
>
> On Friday, May 5, 2017 at 2:21:58 PM UTC+2, Jakob Borg wrote:
>>
>> For end users I strongly recommend distributing a binary. That gives you 
>> the ability to tag it properly and to know what goes into it - your code, 
>> your dependencies, and the compiler used. Typically this would happen by 
>> vendoring and using a Makefile or build script in the repo, running on some 
>> trusted CI platform. 
>>
>> If your end users really should build it themselves, I would have a build 
>> process that describes downloading the code, putting it in the correct 
>> place (...), and using your build script / Makefile. The resulting binary 
>> should know what it is (i.e., what hash it came from and how it was 
>> compiled) and be able to report that to you. 
>>
>> "go get" is a development tool. It does none of the things you need to 
>> happen in a "real" build for end users (imho, ymmv, etc). I would default 
>> your VERSION variable to something like "unsupported-dev" and treat the 
>> binaries correspondingly... "go get" is still perfectly fine for initially 
>> grabbing packages and developer tools where you don't particularly care 
>> what version they are. I sometimes use it as a shortcut for mkdir+git-clone 
>> for non-Go projects. :) 
>>
>> //jb 
>>
>> > On 5 May 2017, at 14:09, mhh...@gmail.com wrote: 
>> > 
>> > Hi, 
>> > 
>> > For a program i provide a pre build binary built with 
>> > 
>> >   go install --ldflags "-X main.VERSION=$VERSION" 
>> > 
>> > So when users met a problem they can report the version easily 
>> > and  certainty. 
>> > 
>> > the version variable is set by default to "0.0.0", could be empty 
>> string. 
>> > 
>> > What should be the cmd line to give the user so that they can go get, 
>> > and set the version to the git hash using the build flag ? 
>> > 
>> > From my computer i could do, 
>> > 
>> > go install --ldflags "-X main.VERSION=`git log | head -n 1`" // or 
>> similar 
>> > 
>> > because i have the repo locally. 
>> > 
>> > But for an end user which did not clone it locally, 
>> > how could that happen in one cross platform command line ? 
>> > 
>> > Note that i might 
>> > - hardcode it into the README or godoc, but that require an additional 
>> control to generate the file containing the instructions, 
>> > - or manual update. 
>> > 
>> > First solution is available only for those who uses such tool, not 
>> everyone. 
>> > Second solution is prone to errors. 
>> > 
>> > thanks. 
>> > 
>> > -- 
>> > 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.


Re: [go-nuts] go get + build flag to set version var

2017-05-05 Thread mhhcbon
I totally agree with you and implemented such build pipeline.

But still, the fact is i have such situation, 
I might run after each and every ticket like this,
that does not seem a run i can win ;)

On Friday, May 5, 2017 at 2:21:58 PM UTC+2, Jakob Borg wrote:
>
> For end users I strongly recommend distributing a binary. That gives you 
> the ability to tag it properly and to know what goes into it - your code, 
> your dependencies, and the compiler used. Typically this would happen by 
> vendoring and using a Makefile or build script in the repo, running on some 
> trusted CI platform. 
>
> If your end users really should build it themselves, I would have a build 
> process that describes downloading the code, putting it in the correct 
> place (...), and using your build script / Makefile. The resulting binary 
> should know what it is (i.e., what hash it came from and how it was 
> compiled) and be able to report that to you. 
>
> "go get" is a development tool. It does none of the things you need to 
> happen in a "real" build for end users (imho, ymmv, etc). I would default 
> your VERSION variable to something like "unsupported-dev" and treat the 
> binaries correspondingly... "go get" is still perfectly fine for initially 
> grabbing packages and developer tools where you don't particularly care 
> what version they are. I sometimes use it as a shortcut for mkdir+git-clone 
> for non-Go projects. :) 
>
> //jb 
>
> > On 5 May 2017, at 14:09, mhh...@gmail.com  wrote: 
> > 
> > Hi, 
> > 
> > For a program i provide a pre build binary built with 
> > 
> >   go install --ldflags "-X main.VERSION=$VERSION" 
> > 
> > So when users met a problem they can report the version easily 
> > and  certainty. 
> > 
> > the version variable is set by default to "0.0.0", could be empty 
> string. 
> > 
> > What should be the cmd line to give the user so that they can go get, 
> > and set the version to the git hash using the build flag ? 
> > 
> > From my computer i could do, 
> > 
> > go install --ldflags "-X main.VERSION=`git log | head -n 1`" // or 
> similar 
> > 
> > because i have the repo locally. 
> > 
> > But for an end user which did not clone it locally, 
> > how could that happen in one cross platform command line ? 
> > 
> > Note that i might 
> > - hardcode it into the README or godoc, but that require an additional 
> control to generate the file containing the instructions, 
> > - or manual update. 
> > 
> > First solution is available only for those who uses such tool, not 
> everyone. 
> > Second solution is prone to errors. 
> > 
> > thanks. 
> > 
> > -- 
> > 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.


Re: [go-nuts] go get + build flag to set version var

2017-05-05 Thread Jakob Borg
For end users I strongly recommend distributing a binary. That gives you the 
ability to tag it properly and to know what goes into it - your code, your 
dependencies, and the compiler used. Typically this would happen by vendoring 
and using a Makefile or build script in the repo, running on some trusted CI 
platform.

If your end users really should build it themselves, I would have a build 
process that describes downloading the code, putting it in the correct place 
(...), and using your build script / Makefile. The resulting binary should know 
what it is (i.e., what hash it came from and how it was compiled) and be able 
to report that to you.

"go get" is a development tool. It does none of the things you need to happen 
in a "real" build for end users (imho, ymmv, etc). I would default your VERSION 
variable to something like "unsupported-dev" and treat the binaries 
correspondingly... "go get" is still perfectly fine for initially grabbing 
packages and developer tools where you don't particularly care what version 
they are. I sometimes use it as a shortcut for mkdir+git-clone for non-Go 
projects. :)

//jb

> On 5 May 2017, at 14:09, mhhc...@gmail.com wrote:
> 
> Hi,
> 
> For a program i provide a pre build binary built with
> 
>   go install --ldflags "-X main.VERSION=$VERSION"
> 
> So when users met a problem they can report the version easily
> and  certainty.
> 
> the version variable is set by default to "0.0.0", could be empty string.
> 
> What should be the cmd line to give the user so that they can go get,
> and set the version to the git hash using the build flag ?
> 
> From my computer i could do,
> 
> go install --ldflags "-X main.VERSION=`git log | head -n 1`" // or similar
> 
> because i have the repo locally.
> 
> But for an end user which did not clone it locally, 
> how could that happen in one cross platform command line ?
> 
> Note that i might 
> - hardcode it into the README or godoc, but that require an additional 
> control to generate the file containing the instructions,
> - or manual update.
> 
> First solution is available only for those who uses such tool, not everyone.
> Second solution is prone to errors.
> 
> thanks.
> 
> -- 
> 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.

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