Bugfix: Add config to disable plugin initialization for Persistent sandbox

[SmartManoj]

Set initialize_plugins=0

---

This PR brings back the old behavior (always initialize). To disable the plugin initialization, one can set init_sandbox_plugins config to 0.

---

For persistent sandboxes, need to run source bashrc.
As source ~/.bashrc was removed in #2172, refactored the logic to execute source ~/.bashrc.
Solves current bug due to the removal, -bash: execute_cli: command not found error.
And with #2177, it won't cause the #2178 problem for persistent sandboxes.

[tobitege]

@SmartManoj
Isn't it possible that the .bashrc contains a (yet unidentified) command that could cause a user interaction and "cause" the hanging still, regardless of where the "source" is called?
I'm not a Linux guy, so had to ask my buddy WizardLM2 and got this as a reply, if that makes sense:

def start_ssh_session(self):
    self.__ssh_login()

    # Instead of sourcing .bashrc directly, you can selectively execute non-interactive parts of it.
    # This is a workaround to prevent hanging due to interactive commands in .bashrc.
    try:
        self.ssh.sendline("source /etc/profile.d/*.sh")  # Source system-wide profiles
        self.ssh.prompt()
        self.ssh.sendline("if [ -z \"$PS1\" ]; then . ~/.bashrc; fi")  # Condition to avoid interactive parts
        self.ssh.prompt()
    except pxssh.ExceptionPxssh as e:
        logger.exception('Failed to source .bashrc: %s', e)
        raise e

    # Fix: https://github.com/pexpect/pexpect/issues/669
    self.ssh.sendline("bind 'set enable-bracketed-paste off'")
    self.ssh.prompt()
    # cd to workspace
    self.ssh.sendline(f'cd {self.sandbox_workspace_dir}')
    self.ssh.prompt()

Further annotation was:
"This modification attempts to source only the parts of .bashrc that are safe for non-interactive sessions. It checks for the presence of the PS1 variable, which is typically set in interactive shells, to decide whether to source .bashrc."

[SmartManoj]

This may be a solution for #2178

---

The current change concerns calling source ~/.bashrc when initializing the plugin.

[tobitege]

The current change concerns calling source ~/.bashrc when initializing the plugin.

Right, it's hard to keep track with the issues. :)

[rbren]

I'm not sure we want to add an option to disable the plugins. That could affect other behavior.

Can you describe the end goal here in more detail? Why does adding this flag help?

[SmartManoj]

#2162

[ryanhoangt]

Just tried it locally and I didn't get execute_cli command not found anymore. Looks good!

[li-boxuan]

I am a bit lost in this feature so I'll leave the review burden to Robert or anyone else 😄 . I just have one request:

once all issues with persistent sandbox are resolved, could you please add it to run-integration-tests.yml? You could add a new line to matrix. We now have three different kinds of sandboxes, and you could add a new dimension - persistent type.

[rbren]

@SmartManoj I still don't understand how/why this works. Does the user need to change the value of init_sandbox_plugins every time they start the app, depending on whether there's an existing sandbox?

Why is init_sandbox_plugins in the top-level configuration, instead of being handled internally like it was before?

[SmartManoj]

It does not need to change every time.
Scenarios:

1. for the manual trigger when a user switches from plugins not needed agents to another agent (happens in tests)
2. when new plugins are added
3. for quick debugging when the Jupyter plugin crashed

[rbren]

Alright. I don't love the top-level config here--it puts too much burden on the user to know when to turn this flag on and off. But let's get this in since it's causing issues.

Long term, better solutions might be:

• Always reboot the sandbox on version change
• Always reboot the sandbox on agent change

[SmartManoj]

This PR brings back the old behavior (always initialize). To disable the plugin initialization, one can set init_sandbox_plugins config to 0.