Re: [ANN] gopack a software dependency management tool for Go

[Alexey Palazhchenko]

Hi Eric,

There is a significant overlap with gonuts.io project, announced earlier: https://groups.google.com/d/msg/golang-nuts/cyt-xteBjr8/zSIAcABKtKAJ

Let's work together to make a good solution, not two bad.

–-–
Alexey "AlekSi" Palazhchenko

[John Asmuth]

Can you explain a little how this improves upon what we've got with go get? Are you trying to include version information, for example?

On Saturday, January 5, 2013 1:36:42 PM UTC-5, Eric wrote:

Hi all, 

I've started coding in go a few months ago, and I really missed a dependency management tool, "à la" maven.

So I started building one.

Of course, I've tried to do my best to keep the minimalistic approach of Go and keep what I've loved about maven. 

So here we are with gopack, no pom.xml files but a plain json file, not meant to be edited by hand, but by command line.

dependencies are really simple, a Package name ( like github.com/eatienza/gopack for instance ) and a Version ( semantic version of course )

remotes are just URL to a remote package repository receiving/serving packages to share them within a team, or with the world.

It can then deliver:

• Building commands
  
• compile ( solve dependencies, and run go install)
• test (solve dependencies, and run go test )
• Managing commands
• append, remove and list dependencies
• append, remove and list remotes
• link missing imports to missing packages, and tries to fix them
• search for packages
• Sharing commands
• download/publish/search  packages from/to remote locations
• act as a remote server
  
• support http://, and file:// protocol

Actually I'm looking for pure go( go1 ) library projects so I can:

• build them with gopack,
  
• get the owner's feedback (is everything ok ?  )
• populate a database of pure go reusable library compatible with gopack.

If any one is interested, please reply here or on the github page (prefered solution to track feedbacks), I'll do my best to configure gopack with your project.

Note that I've been using it on several projects already, and fixed several bugs, I'm not asking for alpha testers, rather looking for projects to do load testing

Any other feedbacks are welcome too.

Regards,

Eric

[André Moraes]

Just a reminder, but go generate static linked binary, with the
exception of cgo linked libraries, those are shared-libraries.

Also, avoid breaking the "go get" behavior. It will make things
complex at the best case scenario.

The problems with "go get" today:
* you can't "get" a specific version (keep the "master" green)
* you can't do custom build steps
* you can't install to a location different from the location that you
downloaded

All those three points are solvable using Makefile and the last
command called is "go build/install"

People using Go expect to have "go get/build/install/doc" working on
every single package after the first install of the given package.
Avoid breaking that expectation.

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

[Eric]

I'm trying to introduce mainly three new stuff:

version: so you depend on a specific version, not the tipping head of a remote repo. Gopack relies on semantic version, and uses 0.0.0 as SNAPSHOT version just like maven

project: a project is a directory containing a pkg, bin and src directory (sounds familiar ;-) ).  Project are the usual stuff that you share on your SCM and that you build on your CI.

repository: place where to find libraries based on package name, and version. Repositories can be either local, or remote. You can then switch from one version to another, share version among your team, and... your CI servers/slaves.

This way, your "project" depends on another project's version, and gopack can find it on the  local repository or download it from any remote repository.

I get, as with maven, the ability to isolate my project's lifecycle from other libraries, or to tighly knit them

I really needed a way to define multiplatform CI project. In my Jenkins, my go projects are free style project (yet) and they looks like:

"gpk compile

gpk test

"

this is already working on any platforms.

There are still some issues to fix, and the compatibility with go get is one of them.

[Eric]

On Monday, January 7, 2013 5:50:35 PM UTC+1, André Moraes wrote:

Just a reminder, but go generate static linked binary, with the
exception of cgo linked libraries, those are shared-libraries.

So far, I'm relying on the lightning fast compilation, and not sharing binaries. This is too tricky to handle both project version, and golang version (binaries from 1.0.2 won't compile with binaries from 1.0.3).

A local repository contains the binaries that are not compiled unless -a option is called (to avoid usuless recompiling) 

Also, avoid breaking the "go get" behavior. It will make things
complex at the best case scenario.

Agreed, I'll do my best to keep it, even if it's difficult. But in case I can't what are the main "benefits" ? 

Is it the way to easily link to another project ?  "go get github/foo/bar" and that's it

or the SCM centric dependency ? "cd github.com/foo/bar; git checkout v1.0.0 " 

 

The problems with "go get" today:
* you can't "get" a specific version (keep the "master" green)

especially with CI, and in team environement

 

* you can't do custom build steps

like generating sources with protobuf (unless you "commit" generated sources !! (OMG this is forbidden by the holly rules of cthulhu !!)

 

* you can't install to a location different from the location that you
downloaded

like forking a repository to fix some stuff, and use it i your project instead of the original code.

 

All those three points are solvable using Makefile and the last
command called is "go build/install"

or gopack ;-)

 

People using Go expect to have "go get/build/install/doc" working on
every single package after the first install of the given package.
Avoid breaking that expectation.

Could you detail the expectation for go build ? isn't go install enough ?

I would add "go test" to the list.

Nevertheless, with gopack, the dependency manager can print out a GOPATH compatible string so you can set your gopath variable with it, and use the full go tool chain as usual.

[Jan Mercl]

On Mon, Jan 7, 2013 at 9:15 PM, Eric <er...@ericaro.net> wrote:
> I'm trying to introduce mainly three new stuff:
> version: so you depend on a specific version, not the tipping head of a
> remote repo. Gopack relies on semantic version, and uses 0.0.0 as SNAPSHOT
> version just like maven

This has been discussed before, perhaps even several times. In short,
there's no both correct and automated solution to certain situations
which can occur naturally with versioning of dependencies. Consider
e.g. a clash of required versions like a1->b1->d1 and a1->c1->d2.

-j