Impossible to handle `SDTOUT` from `zsh-activate-py-environment.plugin.zsh`

[tapyu]

Currently, I am needing to get rid of all STDOUT since you are using it

https://github.com/se-jaeger/zsh-activate-py-environment/blob/60f7d30b927d0d6e37ed8eeba9b788c319e1136e/zsh-activate-py-environment.py#L295

to evaluate this STDOUT in

https://github.com/se-jaeger/zsh-activate-py-environment/blob/60f7d30b927d0d6e37ed8eeba9b788c319e1136e/zsh-activate-py-environment.plugin.zsh#L7

Since you have created a code that depends on this channel to make it work, I am currently getting rid of this SDTOUT with stdout=DEVNULL. .

https://github.com/se-jaeger/zsh-activate-py-environment/blob/60f7d30b927d0d6e37ed8eeba9b788c319e1136e/zsh-activate-py-environment.py#L289

The problem is: This STDOUT that is import too! Without it, when poetry install takes too long, the terminal just become idle for an eternity:

Without printing any information about the installing.

For me, it is clear that the way you've created this plugin is not right. A Unix shell script should create and activate Python environments, not a Python script, let alone resorting the STDOUT of a Python script to activate an environment... STDOUT doesn't serve to trigger a command on the parent process. Rather, it serves to the program communicates to the end user. Try removing stdout=DEVNULL from this command to see how it breaks your code.

Let me know if you agree on this issue. If so and if PRs are welcome, I can take some time to fix it.

[se-jaeger]

Hi, thanks for your feedback. I agree, returning commands to eval via stdout is not really a good solution. However, before we automatically created the environments, this was not a problem. But I'm happy to fix this, if we find a good solution.

Spawning a new process with poetry has the downside that if one leaves this directory, (afaik) we can't kill that process. For me, this was the main idea behind this plugin.

[tapyu]

I agree, returning commands to eval via stdout is not really a good solution.

Great!

But I'm happy to fix this, if we find a good solution.

I do believe that the best solution is handling environment spawning via Unix shell script. It would provide a better compatibility.

Spawning a new process with poetry has the downside that if one leaves this directory, (afaik) we can't kill that process.

I am not sure if I get this problem, why not just exiting the spawned shell?

[se-jaeger]

It's a problem because it's against the initial idea, which was to activate/deactivate environments while traversing through directories. However, if we spawn new shells (which probably would have been the better solution in the first place) and still want to stick to this idea, we need to somehow exit this new shell and then cd to the new directory. At least if the directory is not a sub-directory of the existing (new) shell.

[tapyu]

we need to somehow exit this new shell and then cd to the new directory.

So... Why not just exiting? I got the idea of activating/deactivating environments while going through directories, but I really didn't understand what is the limitation in exiting the current shell and spawning a new one when changing directories.

Anyway, can I try to solve it via Unix shell scripts? If yes, just give some time, I am in the middle of my Doctorate hahahha

[tapyu]

Well, maybe the problem is, once we spawn a new shell as a subprocess of the parent shell, we cannot run the exit command from the parent shell as a command of spawned shell. Is that the problem?

If so, we might still kill this subprocess by sending the KILL signal to the spawned shell, we can use its PID to do so.

[se-jaeger]

Anyway, can I try to solve it via Unix shell scripts?

For sure! I started with shell scripts but my skills are quite limited 😅 And I feel much more comfortable using Python.

If yes, just give some time, I am in the middle of my Doctorate hahahha

Well, good luck then! 😄