-name (git-file-name name version))
(sha256
(base32 "14hdbk0h85930phnsih5k33dj2qx9b3j4vvsf24g6v3qqjvbp54q"
(build-system go-build-system)
(arguments
(list
#:import-path "pkg.nimblebun.works/go-lsp"))
(home-page "https://pkg.nim
On Wed, Jan 11, 2023 at 08:02:15PM -0500, Leo Famulari wrote:
> That's correct. You can put something like this in the package
> arguments:
>
> #:go ,go-1.19
This was undocumented... sorry! I just rectified that in commit
9ec62d1b9c55104f9ab81b95d82988c627a23415.
https://git.savannah.gnu.org/cgi
On Wed, Jan 11, 2023 at 05:25:18PM +, ( wrote:
> Pretty sure there *is* already a #:go argument, but I might be misremembering.
That's correct. You can put something like this in the package
arguments:
#:go ,go-1.19
> Pretty sure there is already a #:go argument, but I might be misremembering.
Just took a look in the build-system and I can't find that argument.
Maybe I didn't search correctly anyway... :)
Cheers!
On Wed Jan 11, 2023 at 1:49 AM GMT, Hilton Chain wrote:
> Though it's possible to package the last version supports Go 1.17 (v1.38.0),
> I wonder if we can
> adjust the build system so that a Go package could be specified via an
> argument in the package
> definition.
Pretty sure there *is* alre
Hilton Chain writes:
> Hi Guix,
>
> I'm trying to package wakatime-cli[1], while Guix uses Go 1.17 as the
> default, the package requires Go 1.19 at the current version
> (v1.60.4).
>
> Though it's possible to package the last version supports Go 1.17
> (v1.38.0), I wonder if we can adjust the bu
e can
> adjust the build system so that a Go package could be specified via an
> argument in the package
> definition.
>
> Thanks!
>
> [1] https://github.com/wakatime/wakatime-cli
I don't know if that's the case for the Go build system but in the gnu build
system
Hi Guix,
I'm trying to package wakatime-cli[1], while Guix uses Go 1.17 as the default,
the package requires
Go 1.19 at the current version (v1.60.4).
Though it's possible to package the last version supports Go 1.17 (v1.38.0), I
wonder if we can
adjust the build system so that a Go package cou
Hi François,
François writes:
> Hello Maxim,
>
> On Tue, Apr 20, 2021 at 10:00:15PM -0400, Maxim Cournoyer wrote:
>> That's exactly what we're doing now (disable Go module with
>> GO11MODULE=off and use GOPATH to find the sources). Debian does
>> something lazy like just calling 'go module vend
Hello Maxim,
On Tue, Apr 20, 2021 at 10:00:15PM -0400, Maxim Cournoyer wrote:
> That's exactly what we're doing now (disable Go module with
> GO11MODULE=off and use GOPATH to find the sources). Debian does
> something lazy like just calling 'go module vendor', which builds a huge
> directory fill
eas! I didn't know that. My high level idea was to mimic
GOPATH but with GOPROXY; instead of source files, we'd have the metadata
+ zip (sources) populated in a given directory (say, the gocache/
subdirectory) of every Go package in Guix, and then could build a union
of these variou
Hello,
I come back to public guix-devel as I think it can be of interest to
others too.
On Sat, Apr 17, 2021 at 08:57:03PM -0400, Maxim Cournoyer wrote:
> JOULAUD François writes:
>
> > I am still unsure of what to do with versions and Go but the ability to
> > pin version will surely be useful
ge makes it so
>> that
>> whether the type of the source, it is unpacked at the expected location
>> given
>> by the IMPORT-PATH of the Go build system.
>>
>> * guix/build/go-build-system.scm: Add the (ice-9 ftw) module.
>> (unpack): Add inn
Hi Mark,
Mark H Weaver writes:
> Hi Maxim,
>
> guix-comm...@gnu.org writes:
>
>> apteryx pushed a commit to branch master
>> in repository guix.
>>
>> commit 7e84d3eef724ef18f8e1c1b0932b6f74d3ae3e35
>> Author: Maxim Cournoyer
>> Date: Thu Apr
Hello again,
guix-comm...@gnu.org writes:
> apteryx pushed a commit to branch master
> in repository guix.
>
> commit f42e4ebb56fe4f16991ca6c6e060c8f3535865cb
> Author: Maxim Cournoyer
> Date: Fri Apr 5 00:00:08 2019 -0400
>
> build: go-build-system: Ensure uni
Hi Maxim,
guix-comm...@gnu.org writes:
> apteryx pushed a commit to branch master
> in repository guix.
>
> commit 7e84d3eef724ef18f8e1c1b0932b6f74d3ae3e35
> Author: Maxim Cournoyer
> Date: Thu Apr 4 23:26:04 2019 -0400
>
> build: go-build-system: Use WHEN for
On Fri, Mar 15, 2019 at 09:40:15PM -0500, Katherine Cox-Buday wrote:
> There is a larger change coming that I think we need to account for. Go
> modules are here (and in v1.13 will be on by default). This feature
> allows Go code to be built outside of a $GOPATH. I'm unsure how this
> information i
Pierre Neidhardt skrev: (15 mars 2019 07:54:49 CET)
>What about adding and extra key #:test-directories that takes a list of
>directories where we would "cd && go test"?
>
>--
>Pierre Neidhardt
>https://ambrevar.xyz/
+1
--
Sent from my k-9 mail for Android.
Leo Famulari writes:
> On Thu, Mar 14, 2019 at 11:54:30PM +0100, Pierre Neidhardt wrote:
>> Erratum: You've packaged go-github-com-kr-text a second time :p
>
> Oops! Fixed in 10b30b97735ba9037f4ce58867f47678d78f4970
>
>> This has happened to me once. I think we should have a linter to protect
>
Leo Famulari writes:
> I just pushed a revamped Go build system with commit
> e3900a4d64e4bf6f426809d6bff058e5a2ae9bc8.
>
> The main change is that instead of putting the list of Go-language
> dependencies store paths in the GOPATH environment variable, these store
> paths a
On Thu, Mar 14, 2019 at 11:51:06PM +0100, Pierre Neidhardt wrote:
> Agreed! This should also make the Go importer more trivial to write/finish!
Okay, I'll try it.
The only part I'm not sure about is what to "build" or "test" for these
library collections. Currently many of them run test suites,
On Thu, Mar 14, 2019 at 11:54:30PM +0100, Pierre Neidhardt wrote:
> Erratum: You've packaged go-github-com-kr-text a second time :p
Oops! Fixed in 10b30b97735ba9037f4ce58867f47678d78f4970
> This has happened to me once. I think we should have a linter to protect
> against this. Thoughts?
I thi
I just pushed a revamped Go build system with commit
e3900a4d64e4bf6f426809d6bff058e5a2ae9bc8.
The main change is that instead of putting the list of Go-language
dependencies store paths in the GOPATH environment variable, these store
paths are union-symlinked into the build directory, and GOPATH
On Thu, Aug 31, 2017 at 08:17:15AM -0400, Leo Famulari wrote:
> I have a work-in-progress of a go-build-system with packages for
> Syncthing up here:
>
> https://github.com/lfam/guix/tree/wip-syncthing
>
> It seems to work until the Syncthing build fails like this:
I'm
Leo Famulari writes:
> On Mon, Aug 28, 2017 at 10:32:41PM +0200, Ricardo Wurmus wrote:
>>
>> Ricardo Wurmus writes:
>>
>> > You could also access the arguments of another package with
>> > “package-arguments”. Using the “properties” field isn’t pretty because
>> > it is a free form alist.
>> >
On Mon, Aug 28, 2017 at 10:32:41PM +0200, Ricardo Wurmus wrote:
>
> Ricardo Wurmus writes:
>
> > You could also access the arguments of another package with
> > “package-arguments”. Using the “properties” field isn’t pretty because
> > it is a free form alist.
> >
> > You can use “find-tail” to
On Tue, Aug 29, 2017 at 03:54:40PM +0300, Frederick Muriithi wrote:
> Maybe the following will help clarify the issue:
>
> The package being built needs the sources of the dependenc(y/ies) to
> be available in its GOPATH.
>
> The build system needs to set the GOPATH such that t
On Mon, Aug 28, 2017 at 10:32:41PM +0200, Ricardo Wurmus wrote:
>
> Ricardo Wurmus writes:
>
> > You could also access the arguments of another package with
> > “package-arguments”. Using the “properties” field isn’t pretty because
> > it is a free form alist.
> >
> > You can use “find-tail” to
Maybe the following will help clarify the issue:
The package being built needs the sources of the dependenc(y/ies) to
be available in its GOPATH.
The build system needs to set the GOPATH such that the Go build system
will find the the dependencies and build against them.
I have a repository[1
Ricardo Wurmus writes:
> You could also access the arguments of another package with
> “package-arguments”. Using the “properties” field isn’t pretty because
> it is a free form alist.
>
> You can use “find-tail” to jump to the keyword in “arguments” and then
> pick the following value.
Here a
Leo Famulari writes:
> So, a Go build system needs to somehow create a symlink union of the
> dependency graph, making the dependencies available at the correct paths
> relative to the root of the build environment. AFAICT, we can't figure
> these paths out programatica
Recently I made some progress on finishing the prototype go-build-system
from Petter [0], and I need some advice.
AFAICT, building a Go program requires the program's Go dependencies to
have a particular filesystem layout, which corresponds to the way these
dependencies are imported b
eal with, so it's understandable that there aren't any go projects in
> guix.
>
> Has there been any progress with this?
Recently I dove in to that prototype of the go-build-system, which does
build a working Syncthing package.
The prototype illustrates what is required for the go-b
I saw some posts back in December about adding syncthing to guix, but
they stopped in January with no noticeable result. I'd like to see
syncthing in guix, although I have an idea of how difficult go is to
deal with, so it's understandable that there aren't any go projects in
guix.
Has there bee
her source has changed, and how that works on Guix.
Optimizations could be made for sure, I will look at this at
convenience.
On 2016-12-16 05:49, Leo Famulari wrote:
On Sun, Dec 11, 2016 at 01:17:48AM +0100, Petter wrote:
From 4c0597a95ae3cd111ef12d675edf501c559458ba Mon Sep 17 00:00:00 2001
Fr
On Sun, Dec 11, 2016 at 01:17:48AM +0100, Petter wrote:
> From 4c0597a95ae3cd111ef12d675edf501c559458ba Mon Sep 17 00:00:00 2001
> From: Petter
> Date: Sun, 11 Dec 2016 01:10:09 +0100
> Subject: [PATCH] gnu: Add Go build system.
>
> * guix/build-system/go.scm: New file
>
oved. In short, it's bad and there's a
> lot to do make it ok-ish. That's where you come in :)
I haven't contributed or carefully studied the other build systems yet,
so my feedback will be rather superficial. I hope somebody with some
more knowledge will jump in :)
&g
dd Syncthing, a sizeable Go project, and its dependencies in a
later e-mail. These recipes uses this Go build system, and my primary
goal has been to make these nice, while functional. Now we can
hopefully work on the build system with a minimum of modifications to
e do not want the omnibus package (we will not be
able to use this easily on guixsd anyway), we need at least a
go-build-system. I have outlined most of what I need to achieve what I
want from GuixSD[0], and go-build-system based packages and items are not
on the list. I will not work on a go-build-s
Yet another "sidequest" because I keep running into walls with
everything:
I've started working on Gogs which requires so many go
dependencies[0] that I started working on a Go build-system.
The resulting packages which will use the go-build-system I would move
into gnu/packages/g
On Tue, Jul 26, 2016 at 07:33:25AM +0100, Christopher Baines wrote:
> On 25/07/16 20:50, Leo Famulari wrote:
> > https://anonscm.debian.org/git/pkg-go/packages/syncthing.git/tree/debian/rules#n42
>
> Just in case you are trying to understand the Debian package, be aware
> that some files are remov
On 25/07/16 20:50, Leo Famulari wrote:
> I don't fully understand Debian's packaging, but it seems that they only
> use external packages to provide 2 of 39 dependencies, bootstrap and
> font-awesome:
> https://anonscm.debian.org/git/pkg-go/packages/syncthing.git/tree/debian/rules#n42
Just in case
On Mon, Jul 25, 2016 at 12:25:40AM +0200, Ludovic Courtès wrote:
> It outlines the command sequence that needs to be run. I’d suggest
> starting from that in ‘go-build-system’. Let’s make it work for this
> package, and then we can adjust if some of the assumptions happened to
> be
On Mon 25 Jul 2016 00:25, l...@gnu.org (Ludovic Courtès) writes:
>> Should Go packages refer to the compiler? This Syncthing package does
>> retain a reference.
>
> I suppose it keeps a reference to run-time support libraries provided by
> the ‘go’ package?
I believe that unless you specifically
uggest
starting from that in ‘go-build-system’. Let’s make it work for this
package, and then we can adjust if some of the assumptions happened to
be specific to Syncthing.
> Should Go packages refer to the compiler? This Syncthing package does
> retain a reference.
I suppose it keeps a r
Now that we have go-1.4 and (almost) go-1.5, we should start thinking
about a go-build-system.
I just wrote my first package using Go, the crude Syncthing package that
is attached. It still needs a lot of work, especially since it builds
Syncthing's dependencies from bundled copies inste
On Sat, Feb 27, 2016 at 09:12:42PM +0200, Efraim Flashner wrote:
> On Fri, 26 Feb 2016 16:36:56 -0500
> Leo Famulari wrote:
>
> > On Fri, Feb 26, 2016 at 03:59:49PM -0500, Thompson, David wrote:
> > > On Fri, Feb 26, 2016 at 2:31 PM, wrote:
> > > > I have lately looked closer at IPFS and I wo
On Fri, 26 Feb 2016 16:36:56 -0500
Leo Famulari wrote:
> On Fri, Feb 26, 2016 at 03:59:49PM -0500, Thompson, David wrote:
> > On Fri, Feb 26, 2016 at 2:31 PM, wrote:
> > > I have lately looked closer at IPFS and I would like to compile and run it
> > > on GuixSD but don't know how to succeed
On Fri, Feb 26, 2016 at 03:59:49PM -0500, Thompson, David wrote:
> On Fri, Feb 26, 2016 at 2:31 PM, wrote:
> > I have lately looked closer at IPFS and I would like to compile and run it
> > on GuixSD but don't know how to succeed without a build system.
>
> We would need a Go toolchain first. I
On Fri, Feb 26, 2016 at 2:31 PM, wrote:
> I have lately looked closer at IPFS and I would like to compile and run it
> on GuixSD but don't know how to succeed without a build system.
We would need a Go toolchain first. I recall at least two people
trying to package Go but no patches have shown
I have lately looked closer at IPFS and I would like to compile and run
it on GuixSD but don't know how to succeed without a build system.
cheers
sdb
51 matches
Mail list logo
