How can I create a command to activate a Python virtual environment across different shells with minimal complexity?

Question

I'm developing a tool that needs to activate a Python virtual environment using a custom command. Currently, I'm using the following alias in my .bashrc file:

alias activate_env="source ./env/bin/activate"

This works well in bash, allowing me to activate the environment by running activate_env in the terminal:

[azom ~]$ ls
env
[azom ~]$ activate_env
Virtual environment activated
(env) [azom ~]$

However, since this tool will be used by others who might use different shells (like zsh, fish, etc.), I want to simplify the process of making this command (activate_env) available across various shell environments.

Problem:

I am creating an installation script for this tool, and I want the script to automatically configure the command (activate_env) for users without requiring manual modifications to their shell configuration files. While I'm fine with modifying user config files, I want to avoid the complexity of updating the appropriate configuration files for every possible shell (.bashrc, .zshrc, config.fish, etc.) through the script.

What I've Tried:

• Aliases: Works fine in bash when added to .bashrc, but I’d need to replicate this for each shell configuration file, which complicates the installation script.
• Symlinks, Functions, and Exports: I explored these options, but I haven’t found a way to make the command (activate_env) available across different shells with the same ease as an alias.

Desired Outcome:

I’m looking for a solution that allows an installation script to set up a command (like activate_env) for activating a Python virtual environment, making it work across various shells (bash, zsh, fish, etc.) with minimal complexity. The goal is to simplify the setup process for end users.

Is there a recommended approach or tool that can help streamline this process?

UPDATE:

I started to look into the actual implementation of the env/bin/activate script. The main part which makes environment actually getting activated is by updating the PATH variable by adding env/bin at the start of it. As far as I know and searched, there is no way of updating the PATH variable from a script and making the changes reflect in the current user session without using source.

I also found out two types of solution for my problem.

The first type is to be able to activate a python environment via a script that does not need source in front of it so it can be used, for example, with a symlink to type a command instead of the script path.

The second type is to be able to add something like alias activate_env="source /path/to/my/activation/script" somewhere such that I don't need to worry about which shell the user decides to install/use.

• Juandev: The question is how the users will get your command. Normally, they install a package from a shell-dedicated directory. So, you could have a script for each shell deployed in each repository. Alternatively, when building it from your website, you can still write guidelines for each shell, and for that, you may need different scripts.
• azom: Initially I was planning to have something like install.sh which would handle everything for them. That way, even people that don't even know what a shell is can use the tool. With the approach of adding something to all shell config files, it gets complicated because the user might not have/use all of the shells, so the install.sh script could get complicated. I am currently looking directly at the activate script in the python env and the main part is to update the PATH variable, but I don't see an easy way to use this without using source. I'll update my question soon with that
• Juandev: but fish many not interpretet your install.sh script well. Thats why I was proposing to check for shell type and have a specific script for each shell.
• azom: After thinking about it, I realized that being able to have a solution for all shells will be near impossible, so I'll have to tricks and sometimes heuristics to get the shell of the user, which is not ideal, but as there is not a unified way to install cli-app afaik, having an install script for each shell or detecting which shell is being used will be my best bet.