Hi! Ludovic Courtès writes: > Here are practical issues that come to mind: > > • It would only work for newer profiles, created after the feature has > been implemented (maybe that’s okay). Indeed, I think it's OK! :) > • The generated files might use APIs that, in the meantime, got > deprecated or changed somehow. This is in contrast with > ‘--export-profile’, which interprets ‘manifest’ (a versioned file > format) and produces code that can use the API du jour. /run/current-system/configuration.scm suffers from the same problem. But with the manifest we could do better, we could include a version number one way or another. Besides, since it comes together with channels.scm, we know which Guix was used, so we always have access to the Guix with the right API to install the manifest. All in all, I think this is not a problem. > • One would still have to learn about these two files, and pick the > right “manifest” file. I think it would be easier than a command. See below. > • For users of ‘-m my-manifest.scm’, we would need to store > ‘my-manifest.scm’ as is instead of generating an approximation > thereof. Which seems easy to do, isn't it? Another use-case which I find useful and comes close to this feature is that of channel/manifest versioning, in the sense of keeping these files under version control for instance in a Git repository. This can be useful to keep the history of everything, even deleted generations, or even in case of hardware failure. To that end, it'd be nice if we could export these files automatically to a designated location. Example: I update ~/my-profile and it automatically produces / overwrite ~/repos/guix-profile-metadata.git/my-profile/channels.scm and ~/repos/guix-profile-metadata.git/my-profile/manifest.scm. This way I can commit these 2 files in my guix-profile-metadata.git repository. Food for thoughts :) -- Pierre Neidhardt https://ambrevar.xyz/