I meant keeping it in a codebase independent of Zsh's.

You are right, bash's --init-file does replace bashrc, so I have to source
that too in my activation script. For my use case I just want to start a
new shell that works the same to the user as when they start a vanilla
shell, with the exception that the virtual environment activation file is
sourced. The activation file sets/modifies a bunch of environment variables
(e.g. PATH, PYTHONHOME and PS1) and changes the working directory. To me
fish shell's --init-command is the most elegant approach, but I can also
live with the same approach as what bash does – in which case I only would
need to source .zshrc in my activation script and not meddle with ZDOTDIR
(which might have unintended side-effects, like what Roman mentioned
regarding the startup files seeing the modified ZDOTDIR instead of what the
user potentially sets it to be).

On Mon, Feb 13, 2023 at 10:46 PM Bart Schaefer <schaefer@brasslantern.com>
wrote:

> On Mon, Feb 13, 2023 at 12:59 PM Kalmár Gergely <kgregory89@gmail.com>
> wrote:
> >
> > Yes, I could do something similar as what zshi does, but that seems like
> a suboptimal solution, because it would require a duplication (and
> indefinite maintenance) of the startup file processing logic in an
> independent codebase.
>
> I don't follow that at all.  You're keeping the file for --init-file
> somewhere now (I presume), so why would pointing ZDOTDIR at it require
> a new codebase?
>
> Anyway "bash --init-file" replaces (both global and user) bashrc
> rather than run the file after them, which doesn't match what you
> originally asked for.  Does it  in fact do what you want?
>
> Does your file need to create internal variables or functions, or is
> it just populating the environment?
>