Hi Guix,
I lost the specific thread on the medium-term road map that applies. A
few suggestions have been made to improve updates the source-only build
systems we have (Rust and Go). I would like to suggest that we do make
changes to these and put them on the road map.
Can we put together some c
On Wed, May 6, 2020 at 3:46 PM Jack Hill wrote:
>
> > Long story short: Guix need not worry about this.
>
> I think we may want to do some work in Guix to support this workflow
> conveniently. That work could include having a secrets management service,
> bootstrapping new hosts for access to the
Dave,
On Wed, 6 May 2020, Thompson, David wrote:
On Sat, Apr 25, 2020 at 5:38 PM Jack Hill wrote:
* Continued development of guix deploy. Figuring out how to deploy secrets
to remote machines would be great.
I used to think this was a problem that guix deploy had to deal with
but after man
On Wed, May 06, 2020 at 01:03:39PM -0400, Thompson, David wrote:
> On Sat, Apr 25, 2020 at 5:38 PM Jack Hill wrote:
> >
> > * Continued development of guix deploy. Figuring out how to deploy secrets
> > to remote machines would be great.
>
> I used to think this was a problem that guix deploy had
On Sat, Apr 25, 2020 at 5:38 PM Jack Hill wrote:
>
> * Continued development of guix deploy. Figuring out how to deploy secrets
> to remote machines would be great.
I used to think this was a problem that guix deploy had to deal with
but after many years doing devops full-time I no longer think t
On Sat, 25 Apr 2020 15:37:44 +0200
Ludovic Courtès wrote:
> Hello Guix!
>
> We released 1.1.0, but what’s coming next? What would you like to
> see?
>
> There are many exciting things being developed and great ideas
> floating around. For myself, I feel like focusing on “consolidating”
> what
Dear,
On Sun, 3 May 2020 at 22:07, Ludovic Courtès wrote:
> We could write a program to build a database locally (I very much like
> the idea of “substitutes” viewed as an optimization compared to local
> computation) but that would be expensive, although it could be
> incremental.
I agree that
Hi,
Jack Hill skribis:
> * Continued development of guix deploy. Figuring out how to deploy
> secrets to remote machines would be great.
Right. I think ‘guix deploy’ development will be fueled by people using
it to do things beyond the simple use cases (the build farm,
single-machine deploymen
Hi,
Pierre Neidhardt skribis:
>> 2. Performance.
>
> At a higher level, we can work on parallelization of builds and
> downloads (all combinations).
>
> Many improvements were suggested in this thread:
>
> https://lists.gnu.org/archive/html/guix-devel/2019-10/msg00694.html
>
> Julien sent
Hi!
Christopher Baines skribis:
> Ludovic Courtès writes:
>
>> We released 1.1.0, but what’s coming next? What would you like to see?
>
> Thanks for starting this thread Ludo, I love this kind of thinking :)
Though I realize now that I have an email problem that introduces a
significant delay
Hey!
Christopher Baines skribis:
> zimoun writes:
>
>> 2. Search on all the packages included in Guix since the Big Bang.
>>
>> It is difficult to find the Guix commit where one package goes in and
>> the commit where it goes out. The Guix Data Service (GDS) helps a lot
>> for that! But AFAIK,
Andy Wingo writes:
>
> I think I have a solution here, as discussed on IRC. Basic idea is to
> make a direct compiler from Tree-IL to bytecode, skipping the CPS step.
> The result won't be optimal in terms of generated code quality (I
> estimate on average 2x slowdown) but it will be very cheap
Andy Wingo writes:
> On Sat 25 Apr 2020 15:37, Ludovic Courtès writes:
>
>> 2. Performance. There are many things we can improve there, first and
>> foremost: the “Computing derivation” part of ‘guix pull’, Guile’s
>> compiler terrible time and space requirements
>
> I think I have a
On Sat 25 Apr 2020 15:37, Ludovic Courtès writes:
> 2. Performance. There are many things we can improve there, first and
> foremost: the “Computing derivation” part of ‘guix pull’, Guile’s
> compiler terrible time and space requirements
I think I have a solution here, as discussed
zimoun writes:
> 2. Search on all the packages included in Guix since the Big Bang.
>
> It is difficult to find the Guix commit where one package goes in and
> the commit where it goes out. The Guix Data Service (GDS) helps a lot
> for that! But AFAIK, it is not possible from the CLI and I do no
Ludovic Courtès writes:
> We released 1.1.0, but what’s coming next? What would you like to see?
Thanks for starting this thread Ludo, I love this kind of thinking :)
> There are many exciting things being developed and great ideas floating
> around. For myself, I feel like focusing on “cons
Hi Ludo,
On Sat, 25 Apr 2020 at 15:38, Ludovic Courtès wrote:
> 4. User interface. Let’s get our act together with ‘guix shell’ and
> ‘guix run-script’, and let’s address other annoyances that
> newcomers keep stumbling upon!
Adding some items to the whishlist. :-)
1. Access to th
I'll echo Jack's suggestions for golang and rust build systems and secrets
deployments. Another quick bit is having a better or documented way to
debug packages and in keeping more packages up to date.
On Sat, 25 Apr 2020, Ludovic Courtès wrote:
Hello Guix!
We released 1.1.0, but what’s coming next? What would you like to see?
…
Thoughts?
Hi Ludo’ et al,
Thanks for your hard work on the 1.1.0 release!
Your proposed direction sounds great to me. To those, I would like to add:
* Impro
19 matches
Mail list logo
