Hi Pierre,
On Wed, 4 Mar 2020 at 09:09, Pierre Neidhardt wrote:
>
> zimoun writes:
>
> >> I sorted the export so that it produces a reproducible output, which is
> >> more version-control friendly.
> >
> > IMHO, the sort would not be too expensive; even on all the packages
> > that Guix already
Hi Ludo,
On Mon, 24 Feb 2020 at 17:16, Ludovic Courtès wrote:
> > ;; Thanks to Ivan Vilata-i-Balaguer for this:
> > (define (guix-commit)
> > (let ((guix-manifest (profile-manifest (string-append (getenv "HOME")
> > "/.config/guix/current"
> > (match (assq 'source
On Tue, 25 Feb 2020 at 11:32, Pierre Neidhardt wrote:
> Ludovic Courtès writes:
> > (Note: we should remove the ‘sort’ call here as the order of packages in
> > the manifest is significant when there are file collisions.)
>
> But the export is not an "internal manifest", it should not need to
Hi Pierre,
Pierre Neidhardt skribis:
> Ludovic Courtès writes:
[...]
>> What we lack is the ability to obtain a “manifest.scm” kind of file
>> (code) that users can pick as a starting point in their migration
>> towards declarative deployment.
>
> You mean a script like the following?
>
> ;;
Howdy!
Pierre Neidhardt skribis:
> Ludovic Courtès writes:
[...]
>> I would, however, use sexps as a serialization format. Compared to an
>> API, an object serialized to an sexp has the advantage that we can write
>> code to handle changes in the serialization format, so it’s future-proof
Howdy!
Turns out I just watched your talk (since I couldn’t be there at the
time!). I was surprised you didn’t explicitly mention ‘guix search’ and
the shortcomings you’d like to address (well, not directly), but I liked
the perspectives!
Hi!
Ludovic Courtès writes:
> Hello!
>
>> The Plan©:
>>
>> On every profile installation, we generate a "specifications.scm" file
>> alongside
>> the internal "manifest".
>
> One thing to keep in mind, though, is that if the ‘specifications.scm’
> is part of the profile, it must be
Hello!
Pierre Neidhardt skribis:
> Ideas that are not that good on second thought:
>
> - Create a profile specification file from CLI options,
> like --export PROFILE or --convert MANIFEST.
>
> The problem is that those are extra steps that the user would have to run
> manually. We can
Pierre Neidhardt writes:
>>> Cleaning up just means updating the profile.
>>
>> You mean with
>>
>> guix upgrade -p /path/to/profile?
Right.
>> OK, but what about a system where you don't have the profile, only the
>> specification file?
OK, that's at the other end, for the user of a
Hi Pierre,
> We've made some progress on the topic during the Guix Days.
Thanks for the summary!
> The Plan©:
>
> On every profile installation, we generate a "specifications.scm" file
> alongside
> the internal "manifest".
Sounds good.
> Problems:
>
> - There may be too many provenances, we
Hi Pierre,
On Thu, 30 Jan 2020 at 20:24, Pierre Neidhardt wrote:
> We've made some progress on the topic during the Guix Days.
Nice that you reported that fast. :-)
> Green light for a patch?
Sounds like a good plan.
All the best,
simon
We've made some progress on the topic during the Guix Days.
First, let's recall some of the use cases:
1. Allow the user to reproduce a profile easily.
2. Keep a profile specification under version control with least effort.
3. Eaysily interface with inferiors (e.g. build a profile with pkg1 and
zimoun writes:
> To me, the aim is to have something compliant between
> /manifest and --manifest. And compliant does not mean that
> /manifest is the entry point for the user specifications.
> What I find a bit odd is: today, --manifest accepts a DSL and Guix
> outputs to /manifest another DSL.
On Mon, 13 Jan 2020 at 15:59, Pierre Neidhardt wrote:
>
> If I understand correctly, it's because of the manifest files need
> information like the store path and the propagated inputs, which are too
> inconvenient for a user-facing "specification file."
Hum? I am not convinced yet. :-)
For
If I understand correctly, it's because of the manifest files need
information like the store path and the propagated inputs, which are too
inconvenient for a user-facing "specification file."
--
Pierre Neidhardt
https://ambrevar.xyz/
signature.asc
Description: PGP signature
Hi Pierre,
On Mon, 13 Jan 2020 at 15:02, Pierre Neidhardt wrote:
> So what's the take-away of this thread?
>
> 1. Simon suggested to add options to convert the manifest to the
> user-friendly specification file (i.e. something compatible with the
> --manifest option).
>
> What about this
Hi Ludo,
On Sun, 12 Jan 2020 at 00:48, Ludovic Courtès wrote:
> Note that it was never designed to be human-friendly. :-) The Scheme
> code passed to ‘--manifest’ is friendlier.
Why do not change a bit both /manifest and code accepted by
'--manifest' to have something consistent and human
Hi,
>> Questions:
>>
>> - Do manifests really need the store path?
>> - Same question about propagated-inputs. Aren't they already encoded in
>> the package definition? Why repeating them here?
>
> This ‘manifest’ file exists mostly for one purpose: to allow incremental
> operations on a
Hi,
Pierre Neidhardt skribis:
>> Basically an entry looks like:
>>
>> --8<---cut here---start->8---
>> ("diffoscope"
>> "131"
>> "out"
>> "/gnu/store/h8zr4rxhvpikv9p07kdjkf2dsrja35wm-diffoscope-131"
>> (propagated-inputs ())
>>
Hi Pierre,
On Wed, 8 Jan 2020 at 16:17, Pierre Neidhardt wrote:
> > a. keep the file /manifest as it is today; and add
> > options to convert it to regular manifests and channels.
> > b. improve the format of this file to obtain consistent manifests.
> >
> > and c. improve what the --manifest
Hi Pierre,
On Mon, 6 Jan 2020 at 21:07, Pierre Neidhardt wrote:
>
> zimoun writes:
>
> >> > Like zimoun writes, it would be nice to have some sort of a “describe”
> >> > command for a regular profile. Actually maybe “guix describe -p”?
> >> >
> >> > Actually ‘guix describe -p ~/.guix-profile’
Hi!
On Thu, 19 Dec 2019 at 17:12, Ludovic Courtès wrote:
> > You have right. It is a bug.
>
> D’oh! Could you file it?
Done in #38673.
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=38673
Cheers,
simon
Hi,
zimoun skribis:
> On Thu, 12 Dec 2019 at 23:35, Pierre Neidhardt wrote:
>>
>> I've seen the "provenance" field mentioned a couple of times before, but
>> I can't see any "provenance" in my $PROFILE/manifest file. Am I missing
>> something?
>>
>> I install profiles with manifests.
>
> You
Hi Pierre,
On Thu, 12 Dec 2019 at 23:35, Pierre Neidhardt wrote:
>
> I've seen the "provenance" field mentioned a couple of times before, but
> I can't see any "provenance" in my $PROFILE/manifest file. Am I missing
> something?
>
> I install profiles with manifests.
You have right. It is a
I've seen the "provenance" field mentioned a couple of times before, but
I can't see any "provenance" in my $PROFILE/manifest file. Am I missing
something?
I install profiles with manifests.
--
Pierre Neidhardt
https://ambrevar.xyz/
signature.asc
Description: PGP signature
Hi Pierre,
On Mon, 9 Dec 2019 at 18:22, Pierre Neidhardt wrote:
>
> Ludovic Courtès writes:
>
> > This is exactly what’s currently implemented if you look at
> > ~/.guix-profile/manifest, under ‘provenance’.
>
> But does "provenance" tell about the channels?
Yes, I think so.
For example,
Ludovic Courtès writes:
> This is exactly what’s currently implemented if you look at
> ~/.guix-profile/manifest, under ‘provenance’.
But does "provenance" tell about the channels?
> Like zimoun writes, it would be nice to have some sort of a “describe”
> command for a regular profile.
Hi!
Konrad Hinsen skribis:
>> One question arises though: channel specifications only make sense for
>> profiles generated with manifests.
>
> Not even for those, if the manifest uses inferior-packages. I'd go for
> per-package channel specifications. They could be optimized (more
> compact,
Hi
Let add some related features. :-)
Some days ago, Konrad proposed [1] a new subcommad (yes another one!
;-) to deal with channels. Mimicking "git remote" management, if I
summarize correctly.
guix channel init
guix channel add URL
guix channel remove
guix channel describe
guix
Pierre Neidhardt writes:
> In this case, how would you intend to use guix time-machine to reproduce
> these profiles?
"guix time-machine" and inferiors are different ways to access specific
Guix versions. "guix time-machine" simply runs a different Guix version.
You can then use it to access
In this case, how would you intend to use guix time-machine to reproduce
these profiles?
--
Pierre Neidhardt
https://ambrevar.xyz/
signature.asc
Description: PGP signature
Hi Pierre,
> One question arises though: channel specifications only make sense for
> profiles generated with manifests.
Not even for those, if the manifest uses inferior-packages. I'd go for
per-package channel specifications. They could be optimized (more
compact, more efficiently usable) by
32 matches
Mail list logo
