Discussion:
What's the best way of packaging golang packages?
(too old to reply)
Iru Cai via arch-general
2017-03-08 16:13:59 UTC
Permalink
Raw Message
Hi,

I'm not familiar with go, but I'm trying to use some go programs, caddy for
example. I read the PKGBUILD of it. It first use `go get' to get the
dependencies and then do the `go build'.

However, I don't think it a good practice. I'm used to the way of
installing the dependency packages first, then install the target package.
Python packages are packaged this way. On the other hand, go packages has
its features. Go programs are compiled to a single binary that do not link
to other go libraries, so they doesn't depend on other go packages.

I also read the Debian Go Packaging document (
https://pkg-go.alioth.debian.org/packaging.html), but I still don't know
when and why we need to make a go package.

I'm also confused when I see node.js packages. I see many of the packages
are built using just an `npm install' so the packaging process will pull a
lot of code, but I think it's better than that in go because the node.js
packages are installed in the user home so that it won't be installed again
when another node.js package needs the same dependency.

Thanks,
Iru
--
Please do not send me Microsoft Office/Apple iWork documents. Send
OpenDocument instead! http://fsf.org/campaigns/opendocument/
Pierre Neidhardt via arch-general
2017-03-08 16:25:51 UTC
Permalink
Raw Message
Post by Iru Cai via arch-general
Go programs are compiled to a single binary that do not link
to other go libraries, so they doesn't depend on other go packages.
You answered your question here, haven't you?
Post by Iru Cai via arch-general
I'm also confused when I see node.js packages. I see many of the packages
are built using just an `npm install' so the packaging process will pull a
lot of code, but I think it's better than that in go because the node.js
packages are installed in the user home so that it won't be installed again
when another node.js package needs the same dependency.
Are you saying that building a go program should re-use user-installed go packages?

Does https://wiki.archlinux.org/index.php/Go_package_guidelines answer your question?

--
Pierre Neidhardt
Iru Cai via arch-general
2017-03-18 11:40:17 UTC
Permalink
Raw Message
Sorry for replying so late but I've just seen this mail.
Post by Pierre Neidhardt via arch-general
Post by Iru Cai via arch-general
Go programs are compiled to a single binary that do not link
to other go libraries, so they doesn't depend on other go packages.
You answered your question here, haven't you?
That's what I think of go packages. They don't depend on any other go
packages, but actually the source code of a lot of go packages depend on
other source packages.
Post by Pierre Neidhardt via arch-general
Post by Iru Cai via arch-general
I'm also confused when I see node.js packages. I see many of the packages
are built using just an `npm install' so the packaging process will pull
a
Post by Iru Cai via arch-general
lot of code, but I think it's better than that in go because the node.js
packages are installed in the user home so that it won't be installed
again
Post by Iru Cai via arch-general
when another node.js package needs the same dependency.
Are you saying that building a go program should re-use user-installed go packages?
Yes, that's my point. I don't like to use `go get` to get other source code
that doesn't belong to the packaged software and is not in PKGBUILD.

Also, if I build go packages without internet access (e.g. in Open Build
System), I can't build this package.
Post by Pierre Neidhardt via arch-general
Does https://wiki.archlinux.org/index.php/Go_package_guidelines answer your question?
--
Pierre Neidhardt
--
Please do not send me Microsoft Office/Apple iWork documents. Send
OpenDocument instead! http://fsf.org/campaigns/opendocument/
Pierre Neidhardt via arch-general
2017-03-19 07:17:05 UTC
Permalink
Raw Message
Sources have to be fetched online at some point anyways. If Internet goes out
after you've fetched the sources, then you can still build the packages.

Regarding user packages: it is not a good idea to use them in PKGBUILDs for
several reasons, first one being that the user is free to change the source code
of Go package locally (change branch, change code). The PKGBUILD must be
reproduicible, so it's better to start afresh.

--
Pierre Neidhardt
Bartłomiej Piotrowski
2017-03-21 10:14:33 UTC
Permalink
Raw Message
Post by Iru Cai via arch-general
Hi,
I'm not familiar with go, but I'm trying to use some go programs, caddy for
example. I read the PKGBUILD of it. It first use `go get' to get the
dependencies and then do the `go build'.
Yes, that's a bad practice, and the fact that devtools allow network
access during build doesn't help.

How Debian and Fedora handles it (and we should too) is packaging source
code that is later being used by the compiler. Semi-example of that can
be found in go-tools[1] package, except golang.org/x/net should be
effectively a standalone package and a make dependency.

The other way is asking upstream to vendor their dependencies in git
repository so we don't need to handle it at all.

Bartłomiej
Bartłomiej Piotrowski
2017-03-21 10:15:31 UTC
Permalink
Raw Message
Post by Bartłomiej Piotrowski
Post by Iru Cai via arch-general
Hi,
I'm not familiar with go, but I'm trying to use some go programs, caddy for
example. I read the PKGBUILD of it. It first use `go get' to get the
dependencies and then do the `go build'.
Yes, that's a bad practice, and the fact that devtools allow network
access during build doesn't help.
How Debian and Fedora handles it (and we should too) is packaging source
code that is later being used by the compiler. Semi-example of that can
be found in go-tools[1] package, except golang.org/x/net should be
effectively a standalone package and a make dependency.
The other way is asking upstream to vendor their dependencies in git
repository so we don't need to handle it at all.
Bartłomiej
And here's the missing link...

[1]
https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/go-tools
Pierre Neidhardt via arch-general
2017-03-21 10:47:05 UTC
Permalink
Raw Message
Many Go tools have fairly generic names. Aren't you afraid of a (possibly future)
naming conflicts by placing them all in /usr/bin/?

--
Pierre Neidhardt
Bartłomiej Piotrowski
2017-03-22 20:58:25 UTC
Permalink
Raw Message
Post by Pierre Neidhardt via arch-general
Many Go tools have fairly generic names. Aren't you afraid of a (possibly future)
naming conflicts by placing them all in /usr/bin/?
--
Pierre Neidhardt
We can detect this, we have the technology
 So until that happens, I
will rest easily.

Bartłomiej

Loading...