unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: ludo@gnu.org (Ludovic Courtès)
To: guix-devel@gnu.org
Subject: Re: make packagers life easier
Date: Mon, 16 Mar 2015 18:01:15 +0100	[thread overview]
Message-ID: <874mpk3mhw.fsf@gnu.org> (raw)
In-Reply-To: <20150315170032.GA14849@venom> ("Tomáš Čech"'s message of "Sun, 15 Mar 2015 18:00:33 +0100")

Hi!

Tomáš Čech <sleep_walker@gnu.org> skribis:

> Stop after/before phase
> =======================
>
> What it can help with?
>
> - download sources of package without constructing URL
> - prepare sources for creating or applying patch

I think ‘guix build -S foo’ does exactly that, doesn’t it?

> - when preparing configure parameters you can stop right after
>  configuration phase
>
> How to implement?
> - inject always failing phase into phases list

I’d like to read what others think because I’m probably biased, but my
first reaction is that (1) I’ve rarely if ever felt the need for this,
(2) adding a failing phase is easy to do by hand, and (3) it would be
hard to implement this generically currently (phases are not exposed.)

> Ommit developed package from generations
> ========================================

Hmm, what do you mean?  For a package to end up in your profile, you
have to explicitly install it.  So I’m really not sure what you mean
here.

> When I work on packages I have to take care of handling generations
> even when I don't care. It complicates removing old package builds
> using `guix gc -d' and it is unwanted burden.

I rarely do ‘guix gc -d’; I rather let the GC collect garbage by itself,
once it a while.  :-)

> Improve output of the build
> ===========================
>
> What I miss?
>
> Mostly one particular and obvious thing - after successful build print
> the path of newly created store in well visible, easy-to-mouse and
> easy-to-parse way.

Successful ‘guix build’ invocations always print the resulting file
name(s) as the last line(s) to stdout, such that one can always do
things like:

  ls $(guix build foo)

Is it what you want, or did you mean something else?

Thanks for the suggestions!

Ludo’.

  reply	other threads:[~2015-03-16 17:01 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-15 17:00 make packagers life easier Tomáš Čech
2015-03-16 17:01 ` Ludovic Courtès [this message]
2015-03-16 18:39   ` Andreas Enge
2015-03-17 12:01 ` Sree Harsha Totakura
2015-03-17 16:12   ` Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=874mpk3mhw.fsf@gnu.org \
    --to=ludo@gnu.org \
    --cc=guix-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).