0

My project team is updating from Python 2 to Python 3.10, and we are trying to replace our old workflow using new tools. In particular, I want to transition from using virtualenv to 3.x's built-in venv module, since it appears that virtualenv is being side-lined in Python 3.

I know that there are some approaches out there:

Emulating Bash 'source' in Python

Activate venv from within Python3 Script

Please note that we are not using Python packages for the purposes of installing wheels for use on PyPI, but instead to install a Python-based product that has its complete requirements housed in a virtual environment on a Ubuntu system.

This is our current workflow:

  • Create a virtual environment using virtualenv
  • Use pip and setuptools to install our base and test requirements into the venv
  • Install the main project into the venv and make the venv relocatable, using virtualenv-make-relocatable
  • Package that into a Ubuntu package to be used for installation

How should we replace the functionality of activate_this.py from the old virtualenv setup?

As I understand it, the activate_this.py script is/was an artifact of virtualenv and remapped various stuff in PATH and in the Python site-packages. So, I could just continue to install this script in my installations and everything would probably work just fine. I could also incorporate the suggestion from the venv module, and source the /path/to/virtual/environment/activate script programmatically in one way or another.

However, is this an appropriate solution? Will it work properly with the future changes that are happening in Python 3.10+?

Karl Knechtel
  • 62,466
  • 11
  • 102
  • 153
Rodney Lott
  • 1
  • 1
  • Welcome to Stack Overflow. Rather than trying to ask for a replacement for an old step in the process, it would be much clearer to explain **directly what you want the new thing to do**. – Karl Knechtel Jan 17 '23 at 14:21
  • I also edited the post to remove quite a bit of redundancy, and what we consider [noise](https://meta.stackoverflow.com/questions/343721). Please keep in mind that this is **not a discussion forum**; your [thanks are implicit](https://meta.stackoverflow.com/questions/288160) and only make it harder to read the whole question. – Karl Knechtel Jan 17 '23 at 14:27
  • As for the issue, though: I didn't understand what you meant about "the future changes that are happening in Python 3.10+", so I left that part alone. But if the goal really is to use virtual environments for **deployment** rather than **development**... you might want to check out [`pipx`](https://pypa.github.io/pipx/) first. It's part of the `pip` ecosystem, and developed and maintained by the same team (the Python Packaging Authority, or PyPA). – Karl Knechtel Jan 17 '23 at 14:29
  • Separately: may I suggest attempting to check *in detail* what `activate_this.py` did, what the current `activate` script does for `venv`-created virtual environments, and see whether there is actually anything else that needs to be addressed? My guess is no, in which case I'm not sure how the other questions you already found are insufficient to address the problem. – Karl Knechtel Jan 17 '23 at 14:32
  • Thanks, @KarlKnechtel for the clarifications and assistance. Regarding the "future changes happening in Python 3.10+", I am referring to what I have read on PyPA documents that suggest that `virtualenv` is being discontinued for use in Python 3, with the replacement, built-in `venv` module. Just like Python 2 is being shelved, I am worried that if I continue to use `virtualenv` that this too will go EOL and I will be stuck. So, I want to make changes that will be more aligned with these deprecations. Thanks for the tip about `pipx`. I'll check that out. – Rodney Lott Jan 17 '23 at 14:45
  • Ah. Python is generally quite generous with deprecation schedules, honestly. The time to start using `venv` was years ago, and it really honestly was hoped that people would start their 3.x migration in, like, 2015 at the latest. The 2020 sunset date already represented an extension compared to the usual schedule, and only because so many people were complaining about breaking changes... that were given huge amounts of advance warning, and advertised using standard best practice for versioning. And which also fix a bunch of things that were blatantly insecure hacks. – Karl Knechtel Jan 17 '23 at 15:02

0 Answers0