FAQ
Hi gophers, here is the open source project for managing packages version
specifically. For now, it provides following commands:

- build: compile and install packages, a shortcut of `go install` + `go
build` + `go run`.
- install: download and install packages with/without specific version.
- remove: simply remove packages in local file system.
- check: check missing dependencies packages of current package.
- search: search packages by keyword.

If you are interested in this project, please
visit: https://github.com/GPMGo/gpm.

Quick start is also available
here: https://github.com/GPMGo/gpm/blob/master/docs/Quick_Start.md

You can either give feedback or *join us*, I recommend the latter one :).

Thanks for your attention for reading this post!

If you have any question and seggestion, please send email:
gpmgo.com@gmail.com

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

  • John Asmuth at May 24, 2013 at 4:54 pm
    This seems to be just a light dressing on "go get". Is there something I'm
    missing?
    On Friday, May 24, 2013 12:45:22 PM UTC-4, Jiahua Chen wrote:

    Hi gophers, here is the open source project for managing packages version
    specifically. For now, it provides following commands:

    - build: compile and install packages, a shortcut of `go install` + `go
    build` + `go run`.
    - install: download and install packages with/without specific version.
    - remove: simply remove packages in local file system.
    - check: check missing dependencies packages of current package.
    - search: search packages by keyword.

    If you are interested in this project, please visit:
    https://github.com/GPMGo/gpm.

    Quick start is also available here:
    https://github.com/GPMGo/gpm/blob/master/docs/Quick_Start.md

    You can either give feedback or *join us*, I recommend the latter one :).

    Thanks for your attention for reading this post!

    If you have any question and seggestion, please send email:
    gpmg...@gmail.com <javascript:>
    --
    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.
  • Jiahua Chen at May 24, 2013 at 5:10 pm
    `go get` calls version control tools underlying, gpm gives you chooses
    whether use it or not. If you want to use like git, hg, gpm simply calls
    `go get`, but if you don't want to, it just downloads code and you can
    configure version of your packages.
    On Friday, May 24, 2013 12:54:24 PM UTC-4, John Asmuth wrote:

    This seems to be just a light dressing on "go get". Is there something I'm
    missing?
    On Friday, May 24, 2013 12:45:22 PM UTC-4, Jiahua Chen wrote:

    Hi gophers, here is the open source project for managing packages version
    specifically. For now, it provides following commands:

    - build: compile and install packages, a shortcut of `go install` + `go
    build` + `go run`.
    - install: download and install packages with/without specific version.
    - remove: simply remove packages in local file system.
    - check: check missing dependencies packages of current package.
    - search: search packages by keyword.

    If you are interested in this project, please visit:
    https://github.com/GPMGo/gpm.

    Quick start is also available here:
    https://github.com/GPMGo/gpm/blob/master/docs/Quick_Start.md

    You can either give feedback or *join us*, I recommend the latter one :).

    Thanks for your attention for reading this post!

    If you have any question and seggestion, please send email:
    gpmg...@gmail.com
    --
    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.
  • Jiahua Chen at May 24, 2013 at 5:12 pm
    and the thing `go get` is missing that it only downloads the latest version
    of package, sure you can go to package's directory and use `git checkout`,
    but gpm does it when you download.
    On Friday, May 24, 2013 12:54:24 PM UTC-4, John Asmuth wrote:

    This seems to be just a light dressing on "go get". Is there something I'm
    missing?
    On Friday, May 24, 2013 12:45:22 PM UTC-4, Jiahua Chen wrote:

    Hi gophers, here is the open source project for managing packages version
    specifically. For now, it provides following commands:

    - build: compile and install packages, a shortcut of `go install` + `go
    build` + `go run`.
    - install: download and install packages with/without specific version.
    - remove: simply remove packages in local file system.
    - check: check missing dependencies packages of current package.
    - search: search packages by keyword.

    If you are interested in this project, please visit:
    https://github.com/GPMGo/gpm.

    Quick start is also available here:
    https://github.com/GPMGo/gpm/blob/master/docs/Quick_Start.md

    You can either give feedback or *join us*, I recommend the latter one :).

    Thanks for your attention for reading this post!

    If you have any question and seggestion, please send email:
    gpmg...@gmail.com
    --
    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.
  • André Moraes at May 24, 2013 at 5:36 pm

    On Fri, May 24, 2013 at 2:12 PM, Jiahua Chen wrote:
    and the thing `go get` is missing that it only downloads the latest version
    of package, sure you can go to package's directory and use `git checkout`,
    but gpm does it when you download.
    Personal opinion:

    If gpm will explicitly break the behavior expected from go get, you
    should change the package path to something controlled by gpm or make
    sure that GPM will work on a isolated GOPATH.

    It's better to have a "package not found error" than other compilation errors.

    --
    André Moraes
    http://amoraes.info

    --
    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.
  • Jiahua Chen at May 24, 2013 at 5:43 pm
    Thanks! That's a good idea, do you mean that gpm downloads packages to
    non-first GOPATH because that's how `go get` does.
    On Friday, May 24, 2013 1:36:47 PM UTC-4, André Moraes wrote:
    On Fri, May 24, 2013 at 2:12 PM, Jiahua Chen wrote:
    and the thing `go get` is missing that it only downloads the latest version
    of package, sure you can go to package's directory and use `git
    checkout`,
    but gpm does it when you download.
    Personal opinion:

    If gpm will explicitly break the behavior expected from go get, you
    should change the package path to something controlled by gpm or make
    sure that GPM will work on a isolated GOPATH.

    It's better to have a "package not found error" than other compilation
    errors.

    --
    André Moraes
    http://amoraes.info
    --
    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.
  • André Moraes at May 24, 2013 at 5:48 pm

    On Fri, May 24, 2013 at 2:42 PM, Jiahua Chen wrote:
    Thanks! That's a good idea, do you mean that gpm downloads packages to
    non-first GOPATH because that's how `go get` does.
    Something like that. But when you call gpm build, the GOPATH used by
    GPM should come first (otherwise, the erros will happen anyway).

    --
    André Moraes
    http://amoraes.info

    --
    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.
  • Jan Mercl at May 24, 2013 at 5:15 pm

    On May 24, 2013 6:54 PM, "John Asmuth" wrote:
    This seems to be just a light dressing on "go get". Is there something
    I'm missing?

    Mayonnaise? ;-)

    -j

    --
    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.
  • Norman Kraft at May 24, 2013 at 8:05 pm

    On Friday, May 24, 2013 12:45:22 PM UTC-4, Jiahua Chen wrote:

    Hi gophers, here is the open source project for managing packages version
    specifically. For now, it provides following commands:

    - build: compile and install packages, a shortcut of `go install` + `go
    build` + `go run`.
    - install: download and install packages with/without specific version.
    - remove: simply remove packages in local file system.
    - check: check missing dependencies packages of current package.
    - search: search packages by keyword.

    If you are interested in this project, please visit:
    https://github.com/GPMGo/gpm.

    Quick start is also available here:
    https://github.com/GPMGo/gpm/blob/master/docs/Quick_Start.md

    You can either give feedback or *join us*, I recommend the latter one :).

    Thanks for your attention for reading this post!

    If you have any question and seggestion, please send email:
    gpmg...@gmail.com <javascript:>

    It has some nice features, but the name is unfortunate. There is already a
    gpm on many Linux systems, the mouse and cut/paste server for Linux
    terminals. I have to use full path specs when I start mine to be sure I get
    the right one.



    --
    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.
  • Jiahua Chen at May 24, 2013 at 10:05 pm
    Thanks!

    What if you change `gpm` to anything else?

    for example, change this name from `gpm` to `gpmgo`, how's this?

    regards.
    On Friday, May 24, 2013 2:59:18 PM UTC-4, Norman Kraft wrote:
    On Friday, May 24, 2013 12:45:22 PM UTC-4, Jiahua Chen wrote:

    Hi gophers, here is the open source project for managing packages version
    specifically. For now, it provides following commands:

    - build: compile and install packages, a shortcut of `go install` + `go
    build` + `go run`.
    - install: download and install packages with/without specific version.
    - remove: simply remove packages in local file system.
    - check: check missing dependencies packages of current package.
    - search: search packages by keyword.

    If you are interested in this project, please visit:
    https://github.com/GPMGo/gpm.

    Quick start is also available here:
    https://github.com/GPMGo/gpm/blob/master/docs/Quick_Start.md

    You can either give feedback or *join us*, I recommend the latter one :).

    Thanks for your attention for reading this post!

    If you have any question and seggestion, please send email:
    gpmg...@gmail.com

    It has some nice features, but the name is unfortunate. There is already a
    gpm on many Linux systems, the mouse and cut/paste server for Linux
    terminals. I have to use full path specs when I start mine to be sure I get
    the right one.

    --
    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.
  • Jiahua Chen at May 25, 2013 at 2:09 am
    In order to avoid more name conflicts, I changed project name to `gopm`,
    here is the link https://github.com/GPMGo/gopm.
    On Friday, May 24, 2013 6:05:27 PM UTC-4, Jiahua Chen wrote:

    Thanks!

    What if you change `gpm` to anything else?

    for example, change this name from `gpm` to `gpmgo`, how's this?

    regards.
    On Friday, May 24, 2013 2:59:18 PM UTC-4, Norman Kraft wrote:
    On Friday, May 24, 2013 12:45:22 PM UTC-4, Jiahua Chen wrote:

    Hi gophers, here is the open source project for managing packages
    version specifically. For now, it provides following commands:

    - build: compile and install packages, a shortcut of `go install` + `go
    build` + `go run`.
    - install: download and install packages with/without specific version.
    - remove: simply remove packages in local file system.
    - check: check missing dependencies packages of current package.
    - search: search packages by keyword.

    If you are interested in this project, please visit:
    https://github.com/GPMGo/gpm.

    Quick start is also available here:
    https://github.com/GPMGo/gpm/blob/master/docs/Quick_Start.md

    You can either give feedback or *join us*, I recommend the latter one
    :).

    Thanks for your attention for reading this post!

    If you have any question and seggestion, please send email:
    gpmg...@gmail.com

    It has some nice features, but the name is unfortunate. There is already
    a gpm on many Linux systems, the mouse and cut/paste server for Linux
    terminals. I have to use full path specs when I start mine to be sure I get
    the right one.

    --
    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.
  • Philippe Lafoucriere at May 25, 2013 at 1:47 pm
    Hi there,

    First of all, congrats on the initiative, it's a great idea, and something
    mandatory if go wants to play in the enterprise.
    I'm coming from the ruby (and ruby on rails) world, and you can't imagine
    the mess we had before bundler was released (http://gembundler.com/).
    The package management was previously something like "go get" (even worse
    actually), and believe me, long term / continuous deployments were a
    nightmare without a good package management.
    Go is relatively young, with just a few libraries/extensions available, it
    will probably suffer from packages incompatibilities one day.

    Anyway, since I'm pretty new to go (and l like it so far!), I wonder how
    you determine the deps here:

    https://github.com/GPMGo/gopm/blob/master/repo/bundles/test_bundle.json

    I should dive into the code to see how you're doing the bundling, but maybe
    our experience from ruby could help:

    - We have a Gemfile to specify the dependancies. This is where all the go
    imports packages should be declared, with a version requirement if needed
    (could be ">=1.2.3", "~>1.2.3" for all 1.2.X versions, etc.)
    - We have a Gemfile.lock to lock down versions. That's one of the beauty of
    bundler, it's like an order: I want foo ">=1.2.3", the current is 1.3.6 so
    this is the version locked. All devs will then use the same exact version,
    and so will your production env.
    - We have .gemspec files for packages (rubygems), to specify dev and
    runtime dependancies.
    - bundler will download and install the required dependancies for the
    current project, in a isolated path

    On top of that, we can have "gemsets" with rvm (ruby version manager), so
    for a specific version of ruby (2.0.0-p195 for instance), a dedicated set
    of gems.
    I hope these hints are helpful, do not hesitate to contact me for more info.

    --
    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.
  • André Moraes at May 27, 2013 at 5:28 pm
    I am not in Go core team, so all text below is just my personal opinion.

    Anyway, since I'm pretty new to go (and l like it so far!), I wonder how you
    determine the deps here:
    https://github.com/GPMGo/gopm/blob/master/repo/bundles/test_bundle.json
    Go std libs have a full AST parser, the dependency can be extracted from there.
    - We have a Gemfile to specify the dependancies. This is where all the go
    imports packages should be declared, with a version requirement if needed
    (could be ">=1.2.3", "~>1.2.3" for all 1.2.X versions, etc.)
    No, Go packages should be declared in the place where they are needed
    (.go files). The thing similar to the Gemfile should list that a given
    import path should use a given repository version.

    github.com/andrebq/gas: af29a85dc92dd5fae1db554c01501c5270c81950
    package import path: vcs revision
    - We have a Gemfile.lock to lock down versions. That's one of the beauty of
    bundler, it's like an order: I want foo ">=1.2.3", the current is 1.3.6 so
    this is the version locked. All devs will then use the same exact version,
    and so will your production env.
    Go create static linked binaries, the production env don't exist, only
    the production binary.
    - We have .gemspec files for packages (rubygems), to specify dev and runtime
    dependancies.
    Go have build constraints where you define when a given file will be
    used to build the final binary (http://golang.org/pkg/go/build/ ->
    Build constraints)
    - bundler will download and install the required dependancies for the
    current project, in a isolated path
    go get + GOPATH solve this problem, plus some vcs management to change
    the checked-out version.
    On top of that, we can have "gemsets" with rvm (ruby version manager), so
    for a specific version of ruby (2.0.0-p195 for instance), a dedicated set of
    gems.
    At this point, there is no need to something like that, go 1.0 made a
    promisse to not break anything. In this case, if something was written
    to go1 it will work with go1.x. Maybe when go 2.0 is out, something
    like this will be required (but only in dev machines).


    --
    André Moraes
    http://amoraes.info

    --
    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 May 27, 2013 at 5:47 pm
    On Mon, 2013-05-27 at 14:28 -0300, André Moraes wrote:
    […]
    Go create static linked binaries, the production env don't exist, only
    the production binary.
    gccgo produces dynamically linked executables, so the production
    environment does exist for that toolchain.

    --
    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
  • Dave Cheney at May 27, 2013 at 11:25 pm
    Which .so libs does a gccgo compiled program reference ?
    On 28/05/2013, at 3:47, Russel Winder wrote:

    On Mon, 2013-05-27 at 14:28 -0300, André Moraes wrote:
    […]
    Go create static linked binaries, the production env don't exist, only
    the production binary.
    gccgo produces dynamically linked executables, so the production
    environment does exist for that toolchain.

    --
    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.
  • Russel Winder at May 28, 2013 at 7:13 am

    On Tue, 2013-05-28 at 09:25 +1000, Dave Cheney wrote:
    Which .so libs does a gccgo compiled program reference ?
    ldd pi_goroutines_multipleChannels
      linux-vdso.so.1 (0x00007fffd79fe000)
      libgo.so.3 => /usr/lib/x86_64-linux-gnu/libgo.so.3 (0x00007fd722f71000)
      libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fd722c73000)
      libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fd722a5c000)
      libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fd7226af000)
      /lib64/ld-linux-x86-64.so.2 (0x00007fd733f14000)
      libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fd722493000)

    This seems to be pretty consistent across my codes, but they are small
    codes.
    --
    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
  • Dave Cheney at May 28, 2013 at 7:16 am
    libgo and libgcc_s looks like the problematic ones, they won't be on
    target machines by default.
    On Tue, May 28, 2013 at 5:13 PM, Russel Winder wrote:
    On Tue, 2013-05-28 at 09:25 +1000, Dave Cheney wrote:
    Which .so libs does a gccgo compiled program reference ?
    ldd pi_goroutines_multipleChannels
    linux-vdso.so.1 (0x00007fffd79fe000)
    libgo.so.3 => /usr/lib/x86_64-linux-gnu/libgo.so.3 (0x00007fd722f71000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fd722c73000)
    libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fd722a5c000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fd7226af000)
    /lib64/ld-linux-x86-64.so.2 (0x00007fd733f14000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fd722493000)

    This seems to be pretty consistent across my codes, but they are small
    codes.
    --
    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.
  • Russel Winder at May 28, 2013 at 8:06 am

    On Tue, 2013-05-28 at 17:16 +1000, Dave Cheney wrote:
    libgo and libgcc_s looks like the problematic ones, they won't be on
    target machines by default.
    But they come packaged as part of GCC, so it you have gccgo then you
    have the libraries.

    --
    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
  • Minux at May 28, 2013 at 9:14 am

    On Tue, May 28, 2013 at 3:16 PM, Dave Cheney wrote:

    libgo and libgcc_s looks like the problematic ones, they won't be on
    target machines by default.
    for the record, libgcc_s.so is essential for gcc compiled programs and it
    should be
    available on any target platform (running gcc compiled programs).

    of course, you can add -static-libgcc to the gccgo command line and static
    link libgcc.a.
    On Tue, May 28, 2013 at 5:13 PM, Russel Winder wrote:
    On Tue, 2013-05-28 at 09:25 +1000, Dave Cheney wrote:
    Which .so libs does a gccgo compiled program reference ?
    ldd pi_goroutines_multipleChannels
    linux-vdso.so.1 (0x00007fffd79fe000)
    libgo.so.3 => /usr/lib/x86_64-linux-gnu/libgo.so.3
    (0x00007fd722f71000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fd722c73000)
    libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1
    (0x00007fd722a5c000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fd7226af000)
    /lib64/ld-linux-x86-64.so.2 (0x00007fd733f14000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
    (0x00007fd722493000)
    This seems to be pretty consistent across my codes, but they are small
    codes.
    --
    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.

    --
    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.
  • Dave Cheney at May 28, 2013 at 9:21 am
    Excellent, that is good to know.
    On Tue, May 28, 2013 at 7:13 PM, minux wrote:
    On Tue, May 28, 2013 at 3:16 PM, Dave Cheney wrote:

    libgo and libgcc_s looks like the problematic ones, they won't be on
    target machines by default.
    for the record, libgcc_s.so is essential for gcc compiled programs and it
    should be
    available on any target platform (running gcc compiled programs).

    of course, you can add -static-libgcc to the gccgo command line and static
    link libgcc.a.

    On Tue, May 28, 2013 at 5:13 PM, Russel Winder <russel@winder.org.uk>
    wrote:
    On Tue, 2013-05-28 at 09:25 +1000, Dave Cheney wrote:
    Which .so libs does a gccgo compiled program reference ?
    ldd pi_goroutines_multipleChannels
    linux-vdso.so.1 (0x00007fffd79fe000)
    libgo.so.3 => /usr/lib/x86_64-linux-gnu/libgo.so.3
    (0x00007fd722f71000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6
    (0x00007fd722c73000)
    libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1
    (0x00007fd722a5c000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6
    (0x00007fd7226af000)
    /lib64/ld-linux-x86-64.so.2 (0x00007fd733f14000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
    (0x00007fd722493000)

    This seems to be pretty consistent across my codes, but they are small
    codes.
    --
    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.
    --
    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 May 28, 2013 at 9:11 am

    On Tue, May 28, 2013 at 1:47 AM, Russel Winder wrote:

    On Mon, 2013-05-27 at 14:28 -0300, André Moraes wrote:
    […]
    Go create static linked binaries, the production env don't exist, only
    the production binary.
    gccgo produces dynamically linked executables, so the production
    environment does exist for that toolchain.
    gccgo can also statically link libgo.

    Just add -static-libgo to the command line.

    after that, the binary will only reference these shared libraries:
      linux-vdso.so.1 (0x00007fff7e3a6000)
    libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fc948453000)
      libm.so.6 => /lib64/libm.so.6 (0x00007fc94815c000)
    libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fc947f46000)
      libc.so.6 => /lib64/libc.so.6 (0x00007fc947b9b000)
    /lib64/ld-linux-x86-64.so.2 (0x00007fc948670000)

    --
    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.
  • Philippe Lafoucrière at May 28, 2013 at 8:33 am

    On Monday, May 27, 2013 7:28:33 PM UTC+2, André Moraes wrote:
    Go std libs have a full AST parser, the dependency can be extracted from
    there.
    Ok, I will take a look :)


    - We have a Gemfile to specify the dependancies. This is where all the go
    imports packages should be declared, with a version requirement if needed
    (could be ">=1.2.3", "~>1.2.3" for all 1.2.X versions, etc.)
    No, Go packages should be declared in the place where they are needed
    (.go files). The thing similar to the Gemfile should list that a given
    import path should use a given repository version.

    github.com/andrebq/gas: af29a85dc92dd5fae1db554c01501c5270c81950
    package import path: vcs revision
    But then, I have to read all .go files to determine dependencies.
    And I don't see how you can fix a version here (apart from the commit,
    which seems a bit fragile to me).
    I think I need to read http://golang.org/doc/code.html now


    Go create static linked binaries, the production env don't exist, only
    the production binary.
    Ok, I missed that one. Good point!


    - We have .gemspec files for packages (rubygems), to specify dev and runtime
    dependancies.
    Go have build constraints where you define when a given file will be
    used to build the final binary (http://golang.org/pkg/go/build/ ->
    Build constraints)
    Thanks for pointing that. Will read.

    - bundler will download and install the required dependancies for the
    current project, in a isolated path
    go get + GOPATH solve this problem, plus some vcs management to change
    the checked-out version.
    Ok, I now _really_ have to check the doc, I think I'm making too much noise
    here :)


    At this point, there is no need to something like that, go 1.0 made a
    promisse to not break anything. In this case, if something was written
    to go1 it will work with go1.x. Maybe when go 2.0 is out, something
    like this will be required (but only in dev machines).

    Sure, but what about packages made for go 1.1 ?
    They won't run on go 1.0, and there's currently no way to know that.
    The only way is to read the README file, but we're talking of automated
    processes here.

    --
    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.
  • André Moraes at May 28, 2013 at 11:36 am

    No, Go packages should be declared in the place where they are needed
    (.go files). The thing similar to the Gemfile should list that a given
    import path should use a given repository version.

    github.com/andrebq/gas: af29a85dc92dd5fae1db554c01501c5270c81950
    package import path: vcs revision

    But then, I have to read all .go files to determine dependencies.
    And I don't see how you can fix a version here (apart from the commit, which
    seems a bit fragile to me).
    I think I need to read http://golang.org/doc/code.html now
    "go get" does that, it will read all .go files and check for imported
    packages, than it will search the package on GOPATH, if the package
    isn't found and the import path is a valid remote path (github.com,
    launchpad.net, your.custom.domain/custom/path) "go get" will try to
    fetch it.

    Take a look at:
    http://golang.org/cmd/go/#hdr-Download_and_install_packages_and_dependencies

    The real problem is when your code requires an specific version
    (rather than the HEAD), this use-case can't be handled by "go get". To
    solve that most people move breaking changes to a different path.
    Doing that allow old code to keep working and new code can break old
    API's.

    labix.org/mgo (http://labix.org/mgo) does that.

    If you need the new version just import using
    (
             "labix.org/v2/mgo"
             "labix.org/v2/mgo/bson"
    )

    The old version would live under
    (
             "labix.org/mgo"
             "labix.org/mgo/bson"
    )

    But some people don't think that behavior is good... I really don't
    understand why.

    In my opinion, doing things that way is much more simple than working
    with vcs commands or playing around with GOPATH to change what code
    will be compiled.


    --
    André Moraes
    http://amoraes.info

    --
    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.
  • Jan Mercl at May 28, 2013 at 11:50 am

    On Tue, May 28, 2013 at 1:36 PM, André Moraes wrote:
    The real problem is when your code requires an specific version
    (rather than the HEAD), this use-case can't be handled by "go get". To
    solve that most people move breaking changes to a different path.
    Doing that allow old code to keep working and new code can break old
    API's.
    That _may_ work in some cases, but it _cannot_ work in the general
    case. Discussed so many times before, that I've nothing more to add to
    it.
    labix.org/mgo (http://labix.org/mgo) does that.

    If you need the new version just import using
    (
    "labix.org/v2/mgo"
    "labix.org/v2/mgo/bson"
    )

    The old version would live under
    (
    "labix.org/mgo"
    "labix.org/mgo/bson"
    )

    But some people don't think that behavior is good... I really don't
    understand why.
    In a nutshell: a1->b1-d1, a1->c1->d2; automatic and correct resolution
    == halting problem.

    -j

    --
    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.
  • André Moraes at May 28, 2013 at 12:04 pm

    In a nutshell: a1->b1-d1, a1->c1->d2; automatic and correct resolution
    == halting problem.
    If d1 and d2 had different import paths, why it would be a problem for a1?
    I can see a problem if the user tried to pass a variable from c1 to b1
    and the type of that var came from "d" package.

    What I am missing?

    --
    André Moraes
    http://amoraes.info

    --
    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.
  • Jan Mercl at May 28, 2013 at 5:16 pm

    On May 28, 2013 2:04 PM, "André Moraes" wrote:
    In a nutshell: a1->b1-d1, a1->c1->d2; automatic and correct resolution
    == halting problem.
    If d1 and d2 had different import paths, why it would be a problem for a1?
    I can see a problem if the user tried to pass a variable from c1 to b1
    and the type of that var came from "d" package.

    What I am missing?
    There are many possible problems with this. Including doubled and not
    connected global state intended to exist only once, init functions run
    twice where only once is correct, type d1.T is not assignment compatible
    with d2.T, but yet such instances can (transitively) appear in a via b and
    c, ... Probably much more which doesn't come to my mind at the moment.

    -j

    --
    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.
  • Dan Kortschak at May 28, 2013 at 12:59 pm

    On Tue, 2013-05-28 at 13:49 +0200, Jan Mercl wrote:
    In a nutshell: a1->b1-d1, a1->c1->d2; automatic and correct resolution
    == halting problem.
    Why is it equivalent to the halting problem, rather than being
    impossible for some other reason?


    --
    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.
  • Jan Mercl at May 28, 2013 at 5:20 pm

    On May 28, 2013 2:59 PM, "Dan Kortschak" wrote:
    On Tue, 2013-05-28 at 13:49 +0200, Jan Mercl wrote:
    In a nutshell: a1->b1-d1, a1->c1->d2; automatic and correct resolution
    == halting problem.
    Why is it equivalent to the halting problem, rather than being
    impossible for some other reason?
    I seem to recall that every undecidable problem is an equivalent of the
    halting problem. My apology if that's not the case. Sure I'm not.

    -j

    --
    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.
  • Dan Kortschak at May 29, 2013 at 1:07 am

    On Tue, 2013-05-28 at 19:20 +0200, Jan Mercl wrote:
    I seem to recall that every undecidable problem is an equivalent of
    the halting problem. My apology if that's not the case. Sure I'm not.
    No need for apology, I'm just trying to figure out if it's formally
    true. I guess it all rests on whether it's undecidable - if it is, then
    I'm sure you're correct. You are probably right, but I'd like to know
    why (this is my problem).

    --
    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.
  • Guilherme Lino at May 29, 2013 at 10:06 am
    First of congratz on the work :)


    But on a personal opinion i think on of the goals of go was avoid config or
    make files. So couldn't you do this:

    import "github.com/go-sql-driver/mysql","tag: v1.0"


    Another thing is, i think you have a field for dependencies of each import,
    but i think each import should already know their dependencies.

    Cumps,
    Guilherme Lino

    Sexta-feira, 24 de Maio de 2013 17:45:22 UTC+1, Jiahua Chen escreveu:
    Hi gophers, here is the open source project for managing packages version
    specifically. For now, it provides following commands:

    - build: compile and install packages, a shortcut of `go install` + `go
    build` + `go run`.
    - install: download and install packages with/without specific version.
    - remove: simply remove packages in local file system.
    - check: check missing dependencies packages of current package.
    - search: search packages by keyword.

    If you are interested in this project, please visit:
    https://github.com/GPMGo/gpm.

    Quick start is also available here:
    https://github.com/GPMGo/gpm/blob/master/docs/Quick_Start.md

    You can either give feedback or *join us*, I recommend the latter one :).

    Thanks for your attention for reading this post!

    If you have any question and seggestion, please send email:
    gpmg...@gmail.com <javascript:>
    --
    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.
  • André Moraes at May 29, 2013 at 12:09 pm

    But on a personal opinion i think on of the goals of go was avoid config or
    make files. So couldn't you do this:

    import "github.com/go-sql-driver/mysql","tag: v1.0"
    You mean to change how the import statement works inside .go files?

    --
    André Moraes
    http://amoraes.info

    --
    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.
  • Sebastien Binet at May 29, 2013 at 12:15 pm

    On Wed, May 29, 2013 at 2:09 PM, André Moraes wrote:
    But on a personal opinion i think on of the goals of go was avoid config or
    make files. So couldn't you do this:

    import "github.com/go-sql-driver/mysql","tag: v1.0"
    You mean to change how the import statement works inside .go files?
    IIRC, the way the content of the import string is interpreted is left
    as an implementation detail.
    so, I believe, this could still be valid go:
    import "github.com/go-sql-driver/mysql @{tag:v1.0}"

    or whatever floats your boat.

    -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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Philippe Lafoucrière at May 29, 2013 at 12:12 pm

    On Wed, May 29, 2013 at 12:06 PM, Guilherme Lino wrote:
    import "github.com/go-sql-driver/mysql","tag: v1.0"
    I like that too, but I see some possible woes.
    Suppose I'm using "mysql" in several go files (because I don't want a
    single 1K LOC file), I have to search in each of them to update the
    version.
    I can grep, of course, but it seems weird to me.

    Another thing is, i think you have a field for dependencies of each import,
    but i think each import should already know their dependencies.
    Each package will have to declare itself with a file in its repo. All
    other packages managers are doing it like this, I don't see another
    way, except a central (/vulnerable / spof / hard to admin) DB.


    --
    Philippe Lafoucrière - CEO
    http://www.tech-angels.com
    main : +33 (0) 970 444 643
    mobile : +33 (0) 6 72 63 75 40
    fax : +33 (0) 9 72 12 78 75

    --
    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.
  • Henry Heikkinen at May 29, 2013 at 12:22 pm
    2013/5/29 Philippe Lafoucrière <philippe.lafoucriere@tech-angels.com>
    On Wed, May 29, 2013 at 12:06 PM, Guilherme Lino wrote:

    import "github.com/go-sql-driver/mysql","tag: v1.0"
    I like that too, but I see some possible woes.
    Suppose I'm using "mysql" in several go files (because I don't want a
    single 1K LOC file), I have to search in each of them to update the
    version.
    I can grep, of course, but it seems weird to me.

    How is that different from the current sitauation? In case of breaking
    changes, instead of simply having to change version number, you have to
    change your code and it's most likely a lot more work.

    One could argue that you have to modify import too often but in my opinion
    it's rarely necessary to always use the very latest version (as in tip).
    Sometimes it can even be a bad idea.
    Another thing is, i think you have a field for dependencies of each import,
    but i think each import should already know their dependencies.
    Each package will have to declare itself with a file in its repo. All
    other packages managers are doing it like this, I don't see another
    way, except a central (/vulnerable / spof / hard to admin) DB.


    --
    Philippe Lafoucrière - CEO
    http://www.tech-angels.com
    main : +33 (0) 970 444 643
    mobile : +33 (0) 6 72 63 75 40
    fax : +33 (0) 9 72 12 78 75

    --
    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.
  • Philippe Lafoucrière at May 29, 2013 at 12:42 pm

    On Wed, May 29, 2013 at 2:22 PM, Henry Heikkinen wrote:
    How is that different from the current sitauation? In case of breaking
    changes, instead of simply having to change version number, you have to
    change your code and it's most likely a lot more work.
    One could argue that you have to modify import too often but in my opinion
    it's rarely necessary to always use the very latest version (as in tip).
    Sometimes it can even be a bad idea.
    Why a version change would imply a code change? Sometimes a version
    bump just improve performances, or fix bugs, or security issues.
    On my rails projects, I often bump gems for that reason, without
    changing loc in the project.



    --
    Philippe Lafoucrière - CEO
    http://www.tech-angels.com
    main : +33 (0) 970 444 643
    mobile : +33 (0) 6 72 63 75 40
    fax : +33 (0) 9 72 12 78 75

    --
    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.
  • Henry Heikkinen at May 29, 2013 at 1:06 pm
    I didn't claim that version change implies a code change. However, even
    without breaking the API a version change might mean new bugs and security
    issues just as much as fixing them so I don't see a problem with being
    explicit about the version.

    A decent solution could be an optioinal version tag and default to
    master/tip.

    2013/5/29 Philippe Lafoucrière <philippe.lafoucriere@tech-angels.com>
    On Wed, May 29, 2013 at 2:22 PM, Henry Heikkinen wrote:
    How is that different from the current sitauation? In case of breaking
    changes, instead of simply having to change version number, you have to
    change your code and it's most likely a lot more work.
    One could argue that you have to modify import too often but in my opinion
    it's rarely necessary to always use the very latest version (as in tip).
    Sometimes it can even be a bad idea.
    Why a version change would imply a code change? Sometimes a version
    bump just improve performances, or fix bugs, or security issues.
    On my rails projects, I often bump gems for that reason, without
    changing loc in the project.


    --
    Philippe Lafoucrière - CEO
    http://www.tech-angels.com
    main : +33 (0) 970 444 643
    mobile : +33 (0) 6 72 63 75 40
    fax : +33 (0) 9 72 12 78 75
    --
    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.
  • Philippe Lafoucrière at May 29, 2013 at 1:18 pm

    On Wed, May 29, 2013 at 3:05 PM, Henry Heikkinen wrote:
    I didn't claim that version change implies a code change. However, even
    without breaking the API a version change might mean new bugs and security
    issues just as much as fixing them so I don't see a problem with being
    explicit about the version.
    Ok, I probably didn't understand correctly then. I'm saying too: being
    explicit about the version is a (very) good thing :)
    A decent solution could be an optioinal version tag and default to
    master/tip.
    Like gemfiles in fact, except bundler will fetch the last stable
    version of the package (instead of master/head). Sometimes master is a
    bit ahead releases.
    A git workflow would then to have "master" branch very stable, then a
    branch for the next unreleased version (say "0.9.0"), and merge all
    (github) pull requests in that branch (instead of master).
    Where it could work, technically, all users will be quickly lost
    because they will probably never start a new branch from
    "release-0.9.0", but "master". This will lead to issues one day :(


    --
    Philippe Lafoucrière - CEO
    http://www.tech-angels.com
    main : +33 (0) 970 444 643
    mobile : +33 (0) 6 72 63 75 40
    fax : +33 (0) 9 72 12 78 75

    --
    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.
  • Henry Heikkinen at May 29, 2013 at 1:27 pm
    Yeah, the hard part is defining the default. You don't want to force people
    to specific workflow but you don't want to make it hard for the users of
    the package either.


    2013/5/29 Philippe Lafoucrière <philippe.lafoucriere@tech-angels.com>
    On Wed, May 29, 2013 at 3:05 PM, Henry Heikkinen wrote:
    I didn't claim that version change implies a code change. However, even
    without breaking the API a version change might mean new bugs and security
    issues just as much as fixing them so I don't see a problem with being
    explicit about the version.
    Ok, I probably didn't understand correctly then. I'm saying too: being
    explicit about the version is a (very) good thing :)
    A decent solution could be an optioinal version tag and default to
    master/tip.
    Like gemfiles in fact, except bundler will fetch the last stable
    version of the package (instead of master/head). Sometimes master is a
    bit ahead releases.
    A git workflow would then to have "master" branch very stable, then a
    branch for the next unreleased version (say "0.9.0"), and merge all
    (github) pull requests in that branch (instead of master).
    Where it could work, technically, all users will be quickly lost
    because they will probably never start a new branch from
    "release-0.9.0", but "master". This will lead to issues one day :(


    --
    Philippe Lafoucrière - CEO
    http://www.tech-angels.com
    main : +33 (0) 970 444 643
    mobile : +33 (0) 6 72 63 75 40
    fax : +33 (0) 9 72 12 78 75
    --
    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.
  • André Moraes at May 29, 2013 at 1:20 pm

    On Wed, May 29, 2013 at 10:05 AM, Henry Heikkinen wrote:
    I didn't claim that version change implies a code change. However, even
    without breaking the API a version change might mean new bugs and security
    issues just as much as fixing them so I don't see a problem with being
    explicit about the version.

    A decent solution could be an optioinal version tag and default to
    master/tip.
    Just to remember that this can be done today, just keep all
    directories from gopath under version control and instead of using "go
    get" check-out the blessed gopath.

    Ofcourse, this don't work when you want your application on github and
    people should just "go get" it.

    --
    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 May 29, 2013 at 2:42 pm
    On Wed, 2013-05-29 at 03:06 -0700, Guilherme Lino wrote:
    […]
    import "github.com/go-sql-driver/mysql","tag: v1.0"
    […]

    I believe Go leaves the version unspecified on the assumption that
    master/HEAD (Git) or default/tip (Mercurial) are intended. There is
    support for Bazaar as well, but I suspect people are stopping using
    Bazaar now.

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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedMay 24, '13 at 4:45p
activeMay 29, '13 at 2:42p
posts40
users14
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase