Hi Pierre,

On Thu, 24 Oct 2019 11:32:55 +0200
Pierre Neidhardt <mail@ambrevar.xyz> wrote:

> As you suggested `guix-activate` could be a shell function that's
> defined in /etc/profile or anywhere appropriate.

Yes, but what's the advantage of that as opposed to just doing it like anyone
else does it: Just start a new shell.

For example

  ssh foo ls

starts ls on the remote host at our terminal

but

  ssh foo

starts an interactive shell on the remote host at our terminal.

Likewise, we could (and do) have 

  guix environment --ad-hoc package1 package2 ls

which starts ls in the guix-environment

but

  guix environment --ad-hoc package1 package2

starts interactive shell in the guix-environment.

Why should it be different with profiles?

I for one *like* it that the shell environment can't be
modified by random programs.

See Windows for how annoying it would be if it were possible for
random programs to change the interactive cmd's environment.

>- The inverse command, =guix deactivate /path/to/profile=.
> This can be useful to deactivate a profile that was activated during login.

That is not composable and sounds like a HUGE effort for what would otherwise
one "exit" command.

>- All commands that accept manifests should be able to compose manifests
>  by passing multiple =--manifest FILE= options.

Hmm that would be nice!