unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Pjotr Prins <pjotr.public12@thebird.nl>
To: John Darrington <john@darrington.wattle.id.au>,
	Pjotr Prins <pjotr.public12@thebird.nl>,
	guix-devel@gnu.org
Subject: Re: Warning on using GUIX_PACKAGE_PATH
Date: Thu, 9 Feb 2017 21:14:03 +0000	[thread overview]
Message-ID: <20170209211403.GA26346@mail.thebird.nl> (raw)
In-Reply-To: <20170209165022.6nt6lefzbr6rspbg@wasp>

On Thu, Feb 09, 2017 at 04:50:23PM +0000, ng0 wrote:
> On 17-02-09 15:08:35, John Darrington wrote:
> > On Thu, Feb 09, 2017 at 01:30:48PM +0000, Pjotr Prins wrote:
> >      @FOSDEM we concluded that GUIX_PACKAGE_PATH does not necessarily work
> >      that wel. I added to my guix-notes the following:
> >      
> >      +Note that, even though GUIX_PACKAGE_PATH can be a feasible way of
> >      +adding and maintaining packages, it has two largish downsides: (1) it
> >      +is removed from the main package tree and therefore not easily shared
> >      +and integrated and (2) to remain compatible you need to juggle two git
> >      +trees which may go out of synch.
> > 
> > 
> > Those are indeed cavaets.  But whether they are "downsides" or "largish" is
> > a matter for individual users to decide.
> > 
> > Some people 1) don't want to share the pacakges they create; and/or 2) are
> > prepared to accept the effort keeping the two things in sync.
> > 
> > J'
> 
> There's a third case: packages which can simply be "as they are" and
> knowing they will not end up in upstream master tree.
> It is easier for me to maintain and experiment with what's the best way
> to provide multiple packages of development versions which depend on
> each other in a guix-package-path, rather than maintain yet another
> branch or yet another full blown guix master repository.

Just to be clear - I agree with both your statements. I merely mean to
warn people that read my notes on the effect of such a choice. It is
something I learnt the hard way. I will still use GUIX_PACKAGE_PATH
until we get channels. That mystical solution that will solve all my
problems ;)

Same for 'guix pull'. It is merely a warning.

Pj.

  reply	other threads:[~2017-02-09 21:17 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-09 13:30 Warning on using GUIX_PACKAGE_PATH Pjotr Prins
2017-02-09 14:08 ` John Darrington
2017-02-09 16:50   ` ng0
2017-02-09 21:14     ` Pjotr Prins [this message]
2017-02-09 19:41 ` Andreas Enge
2017-02-10 12:33 ` 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=20170209211403.GA26346@mail.thebird.nl \
    --to=pjotr.public12@thebird.nl \
    --cc=guix-devel@gnu.org \
    --cc=john@darrington.wattle.id.au \
    /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).