Warning on using GUIX_PACKAGE_PATH

Warning on using GUIX_PACKAGE_PATH

[Pjotr Prins]

@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.

Re: Warning on using GUIX_PACKAGE_PATH

[John Darrington]

[-- Attachment #1: Type: text/plain, Size: 1056 bytes --]

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'

     

-- 
Avoid eavesdropping.  Send strong encrypted email.
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: Warning on using GUIX_PACKAGE_PATH

[ng0]

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'
> 
>      
> 
> -- 
> Avoid eavesdropping.  Send strong encrypted email.
> PGP Public key ID: 1024D/2DE827B3 
> fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
> See http://sks-keyservers.net or any PGP keyserver for public key.
> 

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.

-- 
ng0 -- https://www.inventati.org/patternsinthechaos/

Re: Warning on using GUIX_PACKAGE_PATH

[Pjotr Prins]

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.

Re: Warning on using GUIX_PACKAGE_PATH

[Andreas Enge]

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.

Did we? As everything it depends on the use case, and it seems to be a good
tool for keeping a package or two for personal use. Of course, optimally it
would not be needed, since people write only high quality package definitions
for free software that can easily be upstreamed and accepted as such in the
master branch :-)

Andreas

Re: Warning on using GUIX_PACKAGE_PATH

[Ludovic Courtès]

Hello,

Pjotr Prins <pjotr.public12@thebird.nl> skribis:

> @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.

I’m not sure who “we” is.  :-)

Anyway I think GUIX_PACKAGE_PATH is just that: an environment variable
that allows users to add more packages to Guix’s search path.  It has
never pretended to do more than this, so in that sense the downsides you
mention are “expected”.

It does mean that a higher-level mechanism like channels would be more
than helpful, but it doesn’t mean that GUIX_PACKAGE_PATH is “broken” per se.

Ludo’.