Ability for binary to be placed in current working folder

[ardan-bkennedy]

I appreciate the binary is created in the /bin folder. However, when developing day to day, having the option to place the binary in the current working folder is a convenience that is hard to leave behind. My development workflow is based on this happening every time I hit Save on a code file with main().

[davecheney]

Can you describe your workflow a little more. Because gb has good support
for incremental compilation I've found it simpler to leave the command
prompt at the root of the project and issue gb build there. Then the binary
is always in bin/$PROGRAM

On Sat, 16 May 2015 13:24 William Kennedy notifications@github.com wrote:

I appreciate the binary is created in the /bin folder. However, when
developing day to day, having the option to place the binary in the current
working folder is a convenience that is hard to leave behind. My
development workflow is based on this happening every time I hit Save on a
code file with main().

—
Reply to this email directly or view it on GitHub
#97.

[ardan-bkennedy]

In most cases I am working inside of Sublime, navigating between packages and hitting save to validate the code builds. That works today with gb. Sometimes the package has a main, most of the training repo is like this. When I hit save, I'm expecting a binary to be built to be run.

At first I thought gb was broken building binaries. Then tonight I realized the binary was going to $GOPATH/bin. I don't want these binaries going to bin. I think the strength of gb is its compatibility with the standard GOPATH. However, this is an inconvenience mostly. If this can't change then gb clean becomes very important.

On May 16, 2015, at 12:35 AM, Dave Cheney notifications@github.com wrote:

Can you describe your workflow a little more. Because gb has good support
for incremental compilation I've found it simpler to leave the command
prompt at the root of the project and issue gb build there. Then the binary
is always in bin/$PROGRAM

On Sat, 16 May 2015 13:24 William Kennedy notifications@github.com wrote:

I appreciate the binary is created in the /bin folder. However, when
developing day to day, having the option to place the binary in the current
working folder is a convenience that is hard to leave behind. My
development workflow is based on this happening every time I hit Save on a
code file with main().

—
Reply to this email directly or view it on GitHub
#97.

—
Reply to this email directly or view it on GitHub.

[davecheney]

In most cases I am working inside of Sublime, navigating between packages and hitting save to validate the code builds. That works today with gb. Sometimes the package has a main, most of the training repo is like this. When I hit save, I'm expecting a binary to be built to be run.

Can you configure sublime to always issue gb build all ? That means it won't matter which directory inside the project gb is run inside of.

The reason I'm hesitant to add a -o style option to control the location and name of the output is the disaster that adding a similar flag to the go tool did. -o is tremendously flexible, and thus tremendously confusing and hard to use. I'm going to push back strongly against adding the flag in favour of a simpler and more explainable approach.

[ardan-bkennedy]

On May 16, 2015, at 1:10 AM, Dave Cheney notifications@github.com wrote:

In most cases I am working inside of Sublime, navigating between packages and hitting save to validate the code builds. That works today with gb. Sometimes the package has a main, most of the training repo is like this. When I hit save, I'm expecting a binary to be built to be run.

Can you configure sublime to always issue gb build all ? That means it won't matter which directory inside the project gb is run inside of.

I use gb build -q. I like only building the package I am in.
The reason I'm hesitant to add a -o style option to control the location and name of the output is the disaster that adding a similar flag to the go tool did. -o is tremendously flexible, and thus tremendously confusing and hard to use. I'm going to push back strongly against adding the flag in favour of a simpler and more explainable approach.

I really don't want to specify the location or name. That won't work for me anyway. I just need a wait to build to the current working folder.

Throwing stones. If the name of the binary to be created matches the projects folder name, build to /bin. If not, build to the current working folder.

—
Reply to this email directly or view it on GitHub.

[davecheney]

On 16 May 2015 4:05 pm, "William Kennedy" notifications@github.com wrote:

On May 16, 2015, at 1:10 AM, Dave Cheney notifications@github.com
wrote:

In most cases I am working inside of Sublime, navigating between
packages and hitting save to validate the code builds. That works today
with gb. Sometimes the package has a main, most of the training repo is
like this. When I hit save, I'm expecting a binary to be built to be run.

Can you configure sublime to always issue gb build all ? That means it
won't matter which directory inside the project gb is run inside of.

I use gb build -q. I like only building the package I am in.

Can you explain why this is important to you? Maybe I can find a different
way to support this workflow.

The reason I'm hesitant to add a -o style option to control the
location and name of the output is the disaster that adding a similar flag
to the go tool did. -o is tremendously flexible, and thus tremendously
confusing and hard to use. I'm going to push back strongly against adding
the flag in favour of a simpler and more explainable approach.

I really don't want to specify the location or name. That won't work for
me anyway. I just need a wait to build to the current working folder.

Can you explain why this is not just a special case of building the whole
project? With incremental compilation there should be no difference in
practice, and I really want people to use gb build all.

Throwing stones. If the name of the binary to be created matches the
projects folder name, build to /bin. If not, build to the current working
folder.

This issue isn't about working around the issues -o adds by adding more
special cases. I'd like to understand why you Ned the binary in your
current working directory. And of course, try to find an alternative which
is more consistent with gb's project focus.

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub.

[ardan-bkennedy]

I think there are two things at play here. (1), the need for backwards compatibility with my workflow using the traditional configured GOPATH. (2), how I view what building a binary means.

(1). When I am working, I am focused on one package at a time. I only care if that package builds, vets and lints without fail. Building a binary in this workflow may not happens for days. If I decide to build the binary by moving to that package folder, it is primarily to know the entire project is building, veting, and linting.

The binary that is produced is an artifact not for deployment. It might be run to validate a few things but in many cases it is just removed and the code committed to VC.

(2). I never build a binary in my local environment for deployment. The thought of this actually makes my stomach churn. Code built for deployment should only be built by the CI/CD systems and as automated as possible.

In the case of CI/CD, using the "all" option makes a lot of sense. I expect to be using it for sure. In my development workflow, using "-q" gives me what I want.

The "/bin" folder is for binaries that are to be installed. When I am working, I am never building a binary to be installed. I never want the binary to go to /bin. That is a sacred place that is tied to my environment and/or deployment.

Now I know "gb" changed some of the rules and it can because it is its own tool. It does not sit on top of the current go tool. It has the freedom to do this. However, the tool needs to be respectful to how people work or have been working. If the tool disrupts this too much, then people will feel they can't use it. So my requested changes are not for building code to deploy, they are for the everyday use of the tool as a developer.

-- Bill

On May 17, 2015, at 1:23 AM, Dave Cheney notifications@github.com wrote:

On 16 May 2015 4:05 pm, "William Kennedy" notifications@github.com wrote:

On May 16, 2015, at 1:10 AM, Dave Cheney notifications@github.com
wrote:

In most cases I am working inside of Sublime, navigating between
packages and hitting save to validate the code builds. That works today
with gb. Sometimes the package has a main, most of the training repo is
like this. When I hit save, I'm expecting a binary to be built to be run.

Can you configure sublime to always issue gb build all ? That means it
won't matter which directory inside the project gb is run inside of.

I use gb build -q. I like only building the package I am in.

Can you explain why this is important to you? Maybe I can find a different
way to support this workflow.

The reason I'm hesitant to add a -o style option to control the
location and name of the output is the disaster that adding a similar flag
to the go tool did. -o is tremendously flexible, and thus tremendously
confusing and hard to use. I'm going to push back strongly against adding
the flag in favour of a simpler and more explainable approach.

I really don't want to specify the location or name. That won't work for
me anyway. I just need a wait to build to the current working folder.

Can you explain why this is not just a special case of building the whole
project? With incremental compilation there should be no difference in
practice, and I really want people to use gb build all.

Throwing stones. If the name of the binary to be created matches the
projects folder name, build to /bin. If not, build to the current working
folder.

This issue isn't about working around the issues -o adds by adding more
special cases. I'd like to understand why you Ned the binary in your
current working directory. And of course, try to find an alternative which
is more consistent with gb's project focus.

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub.
—
Reply to this email directly or view it on GitHub.

[davecheney]

Thanks for your reply Bill, but I'm afraid it had only made me more
confused.

On 17 May 2015 10:26 pm, "William Kennedy" notifications@github.com wrote:

I think there are two things at play here. (1), the need for backwards
compatibility with my workflow using the traditional configured GOPATH.
(2), how I view what building a binary means.

(1). When I am working, I am focused on one package at a time. I only
care if that package builds, vets and lints without fail. Building a binary
in this workflow may not happens for days. If I decide to build the binary
by moving to that package folder, it is primarily to know the entire
project is building, veting, and linting.

Ok, so why does it matter if the binary is built in the working directory
or in project/bin? You've just said that your working with packages not
commands.

The binary that is produced is an artifact not for deployment. It might
be run to validate a few things but in many cases it is just removed and
the code committed to VC.

Ok, but you haven't explained why the workflow I gave above is
insufficient.

(2). I never build a binary in my local environment for deployment. The
thought of this actually makes my stomach churn. Code built for deployment
should only be built by the CI/CD systems and as automated as possible.

I agree, but this seems orthogonal to this request

In the case of CI/CD, using the "all" option makes a lot of sense. I
expect to be using it for sure. In my development workflow, using "-q"
gives me what I want.

The "/bin" folder is for binaries that are to be installed. When I am
working, I am never building a binary to be installed. I never want the
binary to go to /bin. That is a sacred place that is tied to my environment
and/or deployment.

I disagree, bin/ and pkg/ are temporary directories that contain cached
artifacts from building code.

This is given further weight as project/bin is rarely in your path.

Now I know "gb" changed some of the rules and it can because it is its
own tool. It does not sit on top of the current go tool. It has the freedom
to do this. However, the tool needs to be respectful to how people work or
have been working. If the tool disrupts this too much, then people will
feel they can't use it. So my requested changes are not for building code
to deploy, they are for the everyday use of the tool as a developer.

I agree with what you have said, but you need to help me understand why you
need binaries created in the current working directory. Please try to focus
on only that issue.

-- Bill

On May 17, 2015, at 1:23 AM, Dave Cheney notifications@github.com
wrote:

On 16 May 2015 4:05 pm, "William Kennedy" notifications@github.com
wrote:

On May 16, 2015, at 1:10 AM, Dave Cheney notifications@github.com
wrote:

In most cases I am working inside of Sublime, navigating between
packages and hitting save to validate the code builds. That works today
with gb. Sometimes the package has a main, most of the training repo is
like this. When I hit save, I'm expecting a binary to be built to be
run.

Can you configure sublime to always issue gb build all ? That means
it
won't matter which directory inside the project gb is run inside of.

I use gb build -q. I like only building the package I am in.

Can you explain why this is important to you? Maybe I can find a
different
way to support this workflow.

The reason I'm hesitant to add a -o style option to control the
location and name of the output is the disaster that adding a similar
flag
to the go tool did. -o is tremendously flexible, and thus tremendously
confusing and hard to use. I'm going to push back strongly against
adding
the flag in favour of a simpler and more explainable approach.

I really don't want to specify the location or name. That won't work
for
me anyway. I just need a wait to build to the current working folder.

Can you explain why this is not just a special case of building the
whole
project? With incremental compilation there should be no difference in
practice, and I really want people to use gb build all.

Throwing stones. If the name of the binary to be created matches the
projects folder name, build to /bin. If not, build to the current
working
folder.

This issue isn't about working around the issues -o adds by adding more
special cases. I'd like to understand why you Ned the binary in your
current working directory. And of course, try to find an alternative
which
is more consistent with gb's project focus.

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub.
—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub.

[codemartial]

I found this issue while trying to figure out where the 'gb' binary got installed. Never knew that I should have $GOPATH/bin listed in my $PATH as well!

I guess what @ardan-bkennedy wants to say is that $GOPATH/bin should be treated the same as, say, /usr/bin, where you drop binaries only when you mean to install them. It's not common for build tools to install binaries in a place like /usr/bin – or even $HOME/bin – unless they're processing an installation target (e.g. make install).

I wonder if defaulting to $PROJECT/bin might work better since it's consistent with expectations from a project-centric layout.

[davecheney]

I wonder if defaulting to $PROJECT/bin might work better since it's consistent with expectations from a project-centric layout

That's what gb does now.

[bketelsen]

Jumping into the pool here. My use case is from a CI environment. Using a docker build image like so:

docker run --rm  -v $(CI_PROJECT_DIR):/go -w /go/src registry.me.com/my/builder:latest gb build my/cmd/api

Because gb is installed in the GOPATH/bin directory, I can't bind-mount the GOPATH/bin directory to get the binary I've built back out of the container (because there'd be no gb binary to build) -- chicken & egg.

If I could specify an output directory, I could bind an /output directory and build to there, grab that binary and put it in a skinny docker container for runtime.

Workarounds are welcomed, if anyone has some.

[davecheney]

Because gb is installed in the GOPATH/bin directory, I can't bind-mount the GOPATH/bin directory to get the binary I've built back out of the container (because there'd be no gb binary to build) -- chicken & egg.

I don't understand what you are saying, gb builds binaries into $PROJECT/bin. It sounds like you need to bind mount $PROJECT into your docker container.