[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Making local development easy
From: |
Alex Sassmannshausen |
Subject: |
Re: Making local development easy |
Date: |
Wed, 25 May 2016 10:23:20 +0200 |
User-agent: |
mu4e 0.9.13; emacs 24.5.1 |
Hello,
Christopher Baines writes:
> Today I had a go at writing a dummy python library, and packaging it,
> and then installing it within an environment, with the aim of
> experimenting more with how Guix works, and to explore how Guix can be
> used as a developer (with unpublished local packages).
>
> There were several slight issues with this, but I got some help on IRC
> to work around these.
I've definitely gone down the same route of wanting to use Guix in local
development. At the moment I'm using
guix environment -l project-guix.scm
to spawn a shell with the full working environment for my project — this
is awesome, but I think it's slightly orthogenal to what you describe.
> The first, is that the hash is required, which I only had to compute
> once, but if I wanted to change the package, I would have to update
> this, which is prohibitive to local development. As an improvement to
> this, could the hash be optional, and if it does not exist, be
> calculated when the build is performed?
>From my perspective, I think silently calculating a hash on the fly if
it is not provided would be problematic: it might lead to laziness in
completing the hash, which would undermine the security model of Guix
(if I understand correctly).
But maybe an explicit flag setting the declaration to "dev-mode", might
be useful?
> 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")).
This, I think, would be great. Specifically, accepting a "file:///"
protocol for (uri)/(git-reference (url)) would be pretty useful…
My 2¢…
Alex
Re: Making local development easy, Andy Wingo, 2016/05/25