Is there opposite of 'go get' in the tool chain ?

[Oleku Konko]

If its so easy to download  and install go apps am curios why there is no default functionality to remove such app when no longer needed

Example 

go get github.com/test/test

Here is my expectation ( Remove all bin,pkg or src related to the package)

go drop github.com/test/test

Is this intentional ? 

[Aram Hăvărneanu]

It's called rm(1).

--
Aram Hăvărneanu

[Matt Harden]

Wow. The OP asked a reasonable question. Go get can put source, binaries and libraries in various parts of the gopath, and it isn't necessarily obvious which files came from which packages.

--
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/groups/opt_out.

[minux]

On Sat, Oct 19, 2013 at 5:50 PM, Matt Harden <matt....@gmail.com> wrote:

Wow. The OP asked a reasonable question. Go get can put source, binaries and libraries in various parts of the gopath, and it isn't necessarily obvious which files came from which packages.

first do go clean -i $importPath

and then rm -rf $GOPATH/src/$importPath

[Archos]

"rm" is a command found in Unix systems but Go also works in Windows systems, so it would be better
something cross-platform like one OP has said.

[minux]

On Sun, Oct 20, 2013 at 2:31 AM, Archos <raul...@sent.com> wrote:

"rm" is a command found in Unix systems but Go also works in Windows systems, so it would be better
something cross-platform like one OP has said.

just use rmdir /s on windows.

is recursively removing a directory difficult enough to warrant a tool?

[Archos]

El domingo, 20 de octubre de 2013 09:48:09 UTC+1, minux escribió:

On Sun, Oct 20, 2013 at 2:31 AM, Archos <raul...@sent.com> wrote:

"rm" is a command found in Unix systems but Go also works in Windows systems, so it would be better
something cross-platform like one OP has said.

just use rmdir /s on windows.

is recursively removing a directory difficult enough to warrant a tool?

It is when you work in different systems, besides of having to write 2 different commands to run a simple task
which could be easily run through a flag added to "go get"

[Russel Winder]

On Sat, 2013-10-19 at 16:50 -0500, Matt Harden wrote:
> Wow. The OP asked a reasonable question. Go get can put source, binaries
> and libraries in various parts of the gopath, and it isn't necessarily
> obvious which files came from which packages.

Not to mention that responses like this begin to create an atmosphere of
aggression and condescension. Scala had a phase like this and it took an
age to get over it. I'd rather not see this happen in the Go community.

As with any other build tool, e.g. make, SCons, Waf, Gradle, Maven, Ant,
etc. there is a clean or remove capability (even if, in some tools, it
has to be programmed). I think it would be good for the go build tool to
do likewise. Like OP, I think:

go drop path/to/package

or some similar name such as remove, purge, etc. would be a valuable
addition to the go command.

--
Russel.
=============================================================================
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel...@ekiga.net
41 Buckmaster Road m: +44 7770 465 077 xmpp: rus...@winder.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder

[Aram Hăvărneanu]

TIL learning two words is too hard.

--
Aram Hăvărneanu

[RickyS]

It's more a question of enabling complete, correct, and portable solutions.

And it's more than two words.  'Go get' can install dependencies.  But 'go drop' probably shouldn't un-install dependencies, as more than one package might depend on them.   This makes it tough for a tool maker, and tough for a human operator.

[Gerard]

The problem of deleting / ignoring dependencies can be solved with yes / no questions.

[Benjamin Measures]

On Sunday, 20 October 2013 11:01:16 UTC+1, Russel Winder wrote:

As with any other build tool, e.g. make, SCons, Waf, Gradle, Maven, Ant,
etc. there is a clean or remove capability

In Go, the counterpart to 'go install' is 'go clean -i'. Read 'go help clean' for more.

What's remains is the src. I'm not familiar with the others you mention, but neither make nor Maven have commands to remove the src. They take the same "attitude" that rm (or OS equiv) will do.

I'd be surprised if the others have a command to remove the source (and makefiles)- if you know of one, please enlighten us.

[Russel Winder]

On Sun, 2013-10-20 at 09:14 -0700, Benjamin Measures wrote:
[…]

> What's remains is the src. I'm not familiar with the others you mention,
> but neither make nor Maven have commands to remove the src. They take the
> same "attitude" that rm (or OS equiv) will do.

make and Maven do not have automated clean, but the common idiom is to
ensure there is a clean operation to abstract over the need to know what
to remove.

> I'd be surprised if the others have a command to remove the source (and
> makefiles)- if you know of one, please enlighten us.

SCons knows how to do a clean because it know how to do a build. cf.
"scons -c"

[minux]

On Oct 20, 2013 3:58 PM, "Russel Winder" <rus...@winder.org.uk> wrote:
>
> On Sun, 2013-10-20 at 09:14 -0700, Benjamin Measures wrote:
> […]
> > What's remains is the src. I'm not familiar with the others you mention,
> > but neither make nor Maven have commands to remove the src. They take the
> > same "attitude" that rm (or OS equiv) will do.
>
> make and Maven do not have automated clean, but the common idiom is to
> ensure there is a clean operation to abstract over the need to know what
> to remove.
>
> > I'd be surprised if the others have a command to remove the source (and
> > makefiles)- if you know of one, please enlighten us.
>
> SCons knows how to do a clean because it know how to do a build. cf.
> "scons -c"

does scons has a option to remove source? this is the main feature request in this thread.

the clean task accomplished by scons -c can be done by go clean -i.

[Michael Jones]

I thought you were going to ask for "go put"

--

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/groups/opt_out.

--

Michael T. Jones | Chief Technology Advocate  | m...@google.com |  +1 650-335-5765

[DisposaBoy]

As you've already been informed: 'go clean' removes bin and pkg. My very strong opinion is that the 'go' tool should not remove files they did not (likely) create which means it shouldn't remove source files because a VCS tool put them there.

[Andrew Gerrand]

On 21 October 2013 05:18, Michael Jones <m...@google.com> wrote:

I thought you were going to ask for "go put"

So did I. :-) That might be more interesting to me, but it shouldn't happen because there are way too many ways to "put" something.

The response "see rm" is a pithy one, but it's also appropriate. While the convenience of "go get" means you can fetch, build, and install Go programs without knowing how Go workspaces (GOPATH) work, you can't seriously develop Go programs without such knowledge. Once you know how to use workspaces, removing installed software is trivially obvious (remove the directories).

This thread inspired me to write this tool for finding unused packages.

  go get github.com/nf/deadleaves

Quoth the package doc:

  Command deadleaves finds and prints the import paths of unused Go packages.

  A package is considered unused if it is not a command ("package main") and

  is not transitively imported by a command.

That should help you find packages that you no longer need.

Andrew

[Oleku Konko]

Holy Crap .. I ran your deadleaves script and i had  34 not used and 9 not found .... This means its easy for unused script to quickly pile up with time especially during evaluation.

I think this should be fully developed , added to the tool chain, and make removal optional  ... and I think agree with Russel Winder that its only proper to have a clean or remove capability

Thanks for the script & quick response ... 

[Matt Harden]

The doc for "go clean" could be improved. By my reading I thought it only removed build artifacts that may have been left in the source directory. I only noticed the "-i" option after it was mentioned here. I do agree that "go clean -i" and "remove source directory" should be easy enough for anyone. And the deadleaves script is awesome.

--

[Andrew Gerrand]

On 21 October 2013 19:19, Oleku Konko <oleku...@gmail.com> wrote:

Holy Crap .. I ran your deadleaves script and i had  34 not used and 9 not found .... This means its easy for unused script to quickly pile up with time especially during evaluation.

I think this should be fully developed , added to the tool chain, and make removal optional  ... and I think agree with Russel Winder that its only proper to have a clean or remove capability

There's nothing really wrong with having a few unused packages lying around. Source code is small and if the code is never imported by anything it won't slow builds. In my tree, deadleaves reported a few hundred packages.  Many were packages included in repositories that contain packages I do use (and thus their presence a good thing). Most were copies of packages that I had made experimental changes to and later discarded (but I'm messy like that). And I've been using this GOPATH for years now.

There are certain risks to automating the removal of anything. Often it's the moment you delete something that you realize you need it. :-) Maybe it would be neat to automatically move the dead leaves to an "attic" gopath to make "working" the tree easier to navigate. But that's not a problem I experience personally, despite my large source tree.

My point in writing deadleaves was to show that it's trivial to write such tools to suit your workflow. It took me less than 15 minutes to write this one. But I don't think I'll use it, let alone incorporate it in the standard tool chain. That it is "only proper" is not a sound technical argument for a new feature. ;-)

Andrew