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

--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

  • Aram Hăvărneanu at Oct 19, 2013 at 9:20 pm
    It's called rm(1).

    --
    Aram Hăvărneanu

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Matt Harden at Oct 19, 2013 at 9:50 pm
    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.
    On Sat, Oct 19, 2013 at 4:20 PM, Aram Hăvărneanu wrote:

    It's called rm(1).

    --
    Aram Hăvărneanu

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Minux at Oct 20, 2013 at 12:11 am

    On Sat, Oct 19, 2013 at 5:50 PM, 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.
    first do go clean -i $importPath
    and then rm -rf $GOPATH/src/$importPath

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Archos at Oct 20, 2013 at 6:31 am
    "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.

    El domingo, 20 de octubre de 2013 01:11:23 UTC+1, minux escribió:

    On Sat, Oct 19, 2013 at 5:50 PM, Matt Harden <matt....@gmail.com<javascript:>
    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
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Minux at Oct 20, 2013 at 8:48 am

    On Sun, Oct 20, 2013 at 2:31 AM, Archos 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?

    El domingo, 20 de octubre de 2013 01:11:23 UTC+1, minux escribió:
    On Sat, Oct 19, 2013 at 5:50 PM, 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.
    first do go clean -i $importPath
    and then rm -rf $GOPATH/src/$importPath
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Archos at Oct 20, 2013 at 8:54 am
    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 <javascript:>>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"

    El domingo, 20 de octubre de 2013 01:11:23 UTC+1, minux escribió:
    On Sat, Oct 19, 2013 at 5:50 PM, 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.
    first do go clean -i $importPath
    and then rm -rf $GOPATH/src/$importPath
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Aram Hăvărneanu at Oct 20, 2013 at 10:01 am
    TIL learning two words is too hard.

    --
    Aram Hăvărneanu

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • RickyS at Oct 20, 2013 at 10:24 am
    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.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Gerard at Oct 20, 2013 at 10:29 am
    The problem of deleting / ignoring dependencies can be solved with yes / no
    questions.
    On Sunday, October 20, 2013 12:24:20 PM UTC+2, RickyS wrote:

    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.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Russel Winder at Oct 20, 2013 at 10:01 am

    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.winder@ekiga.net
    41 Buckmaster Road m: +44 7770 465 077 xmpp: russel@winder.org.uk
    London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Benjamin Measures at Oct 20, 2013 at 4:14 pm

    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.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Russel Winder at Oct 20, 2013 at 7:58 pm
    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"

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

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Minux at Oct 20, 2013 at 8:05 pm

    On Oct 20, 2013 3:58 PM, "Russel Winder" 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.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Michael Jones at Oct 20, 2013 at 8:19 pm
    I thought you were going to ask for "go put"

    On Sun, Oct 20, 2013 at 1:05 PM, minux wrote:

    On Oct 20, 2013 3:58 PM, "Russel Winder" 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.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.


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

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Andrew Gerrand at Oct 21, 2013 at 8:21 am

    On 21 October 2013 05:18, Michael Jones 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

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Oleku Konko at Oct 21, 2013 at 10:19 am
    Holy Crap .. I ran your deadleaves script <https://github.com/nf/deadleaves>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 ...

    On Monday, October 21, 2013 9:20:35 AM UTC+1, Andrew Gerrand wrote:


    On 21 October 2013 05:18, Michael Jones <m...@google.com <javascript:>>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
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Matt Harden at Oct 21, 2013 at 12:40 pm
    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.

    On Mon, Oct 21, 2013 at 5:19 AM, Oleku Konko wrote:

    Holy Crap .. I ran your deadleaves script<https://github.com/nf/deadleaves>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 ...

    On Monday, October 21, 2013 9:20:35 AM UTC+1, Andrew Gerrand wrote:

    On 21 October 2013 05:18, Michael Jones 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
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Andrew Gerrand at Oct 21, 2013 at 4:01 pm

    On 21 October 2013 19:19, Oleku Konko wrote:

    Holy Crap .. I ran your deadleaves script<https://github.com/nf/deadleaves>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

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • DisposaBoy at Oct 21, 2013 at 6:19 am
    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.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedOct 19, '13 at 8:10p
activeOct 21, '13 at 4:01p
posts20
users12
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase