In conda packages activate scripts are supported.
Is this available in case of wheels as well?
I associate activate / deactivate scripts with a venv, not a wheel. Any wheel can be installed into any venv. Does conda create a venv automatically for each package?
Yes the activate and deactivate scripts are env specific.
But in conda, individual package recipes are permitted to have these - Activate scripts — conda-build 0.0.0.dev0+placeholder documentation.
1 Like
Venv doesn’t support this, and I’ve heard Conda-adjacent folk say they wish they never added it.
If you need the user to set additional environment variables before running your code, the best place to put it is in the code itself. .pth files can import modules/run code that modify the environment when Python is launched, which may also be an alternative.
Python venv’s are not intended for running anything but Python. Conda’s envs are much more broad, and so they have features to help non-Python tools as well.
3 Likes
I definitely count as conda-adjacent, and I agree in principle, though I wouldn’t go that far. It’s a hack that’s unfortunately sometimes necessary (given current constraints) – though in fairness, what I’m talking about goes far beyond python packages, e.g. we need to ensure we’re able to correctly set up compilers to look in the right places for libraries, headers, etc.
The vast majority of python-centric packages shouldn’t require activation, and I would strongly discourage use of activation scripts if the same effect can be achieved in another way. As a counter-example, here’s a case that I cannot see another way of fixing[1]:
Wanting to use gdb with (py)arrow on linux requires a path like $PREFIX/share/gdb/auto-load/$PREFIX/lib to exist. The stacking of the paths is intentional and necessary, but the problem is that we don’t know the actual value of $PREFIX until the installation happens, so we cannot do that in a generic, relocatable way out of the box.
But ultimately, what activation scripts come down to are hooks to ensure something happens after install time and/or upon entering (or exiting) the environment. A lot of this could be broken down a few major cases (e.g. set these environment variables), but it’s still hard to define an interface around this, which would allow for the respective activation scripts (much less all of them) to be replaced with something more structured and constrained than free-form script execution.
well, unless one writes probing & creation logic for this into pyarrow itself, which moves an originally install-time concern (for non-relocatable installs at least) to runtime. ↩︎
3 Likes
Another key difference is activation scripts for virtual environments are entirely a developer convenience and in no way required to use a virtual environment. That has real benefit when working with virtual environments (e.g. you don’t need to run a shell just to run the Python interpreter in the virtual environment which is problematic for tools that work with virtual environments).
Keeping the activation scripts as optional for virtual environments is a hill I’m willing to die on.
7 Likes
Strongly agreed about the point that activation is optional. It’s a good goal that venv/bin/python and source venv/bin/activate; python have as few behavior differences as possible.
@deepali31 - what is the thing you would want to do in an activate/deactivate script? I’d like to figure out if there’s a way to do it that makes it work properly when running venv/bin/activate directly.
2 Likes
Same here. In all the years I’ve used venvs, both in development and production, I’ve never activated one.
2 Likes