Ricardo Wurmus <rek...@elephly.net> skribis: > Christopher Baines <m...@cbaines.net> writes: > >> On 25/05/16 11:29, Ricardo Wurmus wrote: >>> Christopher Baines <m...@cbaines.net> writes: >>>> The second issue was getting the data to the store, as first I tried a >>>> relative path, but that did not work, and ended up having to expose the >>>> repository using a HTTP server, and access it over the loopback >>>> interface. This again is rather prohibitive to local development. To >>>> improve on this, could guix build do the insertion in to the store, such >>>> that relative paths would work? This would allow just writing a >>>> "guix.scm" file, which just uses (git-reference (url "./") (commit >>>> "HEAD")). >>> >>> Maybe I’m misunderstanding the problem, but do you know that you can use >>> “file://” URIs? I’m doing this for local copies of tarballs that I >>> don’t plan to distribute. >> >> I did try this, but it did not work. davexunit on IRC said that this was >> due to the isolation in the build process. I was trying to reference >> /tmp, where did you place the repository to make this work? > > I’m using something like this and it works just right: > > (source (origin > (method url-fetch) > (uri (string-append "file:///srv/some/tarball-v" > version ".tar.gz")) > (sha256 > (base32 > "...")))) > > I used /srv but also /gnu and other locations.
Even shorter: (source "/some/file/out/there") or: (source ".") Also, in some cases, --with-source might work for you (info "(guix) Package Transformation Options"): guix build my-package --with-source=my-package-0.1.3rc2.tar.gz Ludo’.