[go-nuts] gpm(Go Package Manager) is on the way.

This seems to be just a light dressing on "go get". Is there something I'm
missing?

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

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.

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

I'm missing?

Mayonnaise? ;-)

-j

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.

Thanks!

What if you change `gpm` to anything else?

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

regards.

In order to avoid more name conflicts, I changed project name to `gopm`,
here is the link https://github.com/GPMGo/gopm.

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.

I am not in Go core team, so all text below is just my personal opinion.

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
Go create static linked binaries, the production env don't exist, only
the production binary.
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)
go get + GOPATH solve this problem, plus some vcs management to change
the checked-out version.
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).

On Mon, 2013-05-27 at 14:28 -0300, André Moraes wrote:
[…]
gccgo produces dynamically linked executables, so the production
environment does exist for that toolchain.

Which .so libs does a gccgo compiled program reference ?

  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.

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.

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.

Excellent, that is good to know.

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)

Ok, I will take a look :)


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
Ok, I missed that one. Good point!


Thanks for pointing that. Will read.

Ok, I now _really_ have to check the doc, I think I'm making too much noise
here :)



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.

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

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.
In a nutshell: a1->b1-d1, a1->c1->d2; automatic and correct resolution
== halting problem.

-j

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

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

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

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:

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

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.

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.

2013/5/29 Philippe Lafoucrière <[email protected]>
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.

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 <[email protected]>

Ok, I probably didn't understand correctly then. I'm saying too: being
explicit about the version is a (very) good thing :)
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 :(

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 <[email protected]>

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.

On Wed, 2013-05-29 at 03:06 -0700, Guilherme Lino wrote:
[…]
[…]

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.