# Add a global switch to disable the container requirement? **URL:** \ **Category:** Python Help\ **Tags:** help\ **Created:** [October 3, 2026, 6:55am UTC](https://discuss.python.org/t/add-a-global-switch-to-disable-the-container-requirement/109335 "2026-10-03T06:55:14Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![jharris1993](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/jharris1993/32/37747_2.png) [@jharris1993](https://discuss.python.org/u/jharris1993)\ **Post date:** [October 3, 2026, 6:55am UTC](https://discuss.python.org/t/add-a-global-switch-to-disable-the-container-requirement/109335/1 "2026-10-03T06:55:14Z")
Greetings! I understand that, in general, the “–yes\_i’m\_a-blithering\_idiot” (–break\_system\_packages) is, generally, useful. However, it excludes the case where Python _ **IS** _ the system packages - like a hardware robot where Python needs low-level access to the hardware without an additional abstraction layer. I would like to see a global switch somewhere, like `containers=off,`that would force Python into legacy mode. Does this already exist? Can we do something like this? Thanks! Jim ---
**Author:** ![jharris1993](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/jharris1993/32/37747_2.png) [@jharris1993](https://discuss.python.org/u/jharris1993)\ **Post date:** [October 3, 2026, 12:57pm UTC](https://discuss.python.org/t/add-a-global-switch-to-disable-the-container-requirement/109335/2 "2026-10-03T12:57:23Z")
Update: This particular robot currently uses Raspbian Buster, Python 3.7 and I want to update to later versions of Raspberry Pi O/S which use a later version of Python. Porting the software and testing it with the robot is already difficult enough. Adding containers creates another level of doubt: Is the problem software related, hardware related, or perhaps something wrong with the way the container is configured? Thank you for your consideration. Jim ---
**Author:** ![DavidCEllis](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/davidcellis/32/9789_2.png) [@DavidCEllis](https://discuss.python.org/u/DavidCEllis)\ **Post date:** [October 3, 2026, 2:37pm UTC](https://discuss.python.org/t/add-a-global-switch-to-disable-the-container-requirement/109335/3 "2026-10-03T14:37:53Z")
It’s a little hard to say without making some assumptions about what you’re trying to do so apologies if I’m slightly off here. If you’re trying to install something with `pip` and seeing the `This environment is externally managed` message you don’t need a container to get around this or to potentially break things with `--break-system-packages` on every `pip` invocation. A virtual environment is sufficient\[1\]. This is essentially just a folder with its own set of packages and a python ‘executable’ that will include these packages in its `sys.path` when run. Essentially if your robot currently uses: ```python /usr/bin/pip install -r requirements.txt ``` To run with: ```python /usr/bin/python robot_script.py ``` The direct replacement would be something like this: ```python /usr/bin/python -m venv ~/robot_venv ~/robot_venv/bin/pip install -r requirements.txt ``` To run with: ```python ~/robot_venv/bin/python robot_script.py ``` Replacing `~/robot_venv` with wherever you want to store the virtual environment. Note: If you are relying on some system python packages alongside those installed with `pip` you need to add **`--system-site-packages`** to the initial `venv` command to include those in the environment. * * * 1. I believe `python3-venv` is usually installed by default on Raspberry Pi OS? You may need to install that if `python -m venv` fails. ---
**Author:** ![MegaIng](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/megaing/32/16162_2.png) [@MegaIng](https://discuss.python.org/u/MegaIng)\ **Post date:** [October 3, 2026, 9:38pm UTC](https://discuss.python.org/t/add-a-global-switch-to-disable-the-container-requirement/109335/4 "2026-10-03T21:38:20Z")
> [@jharris1993](#): > > I would like to see a global switch somewhere, like `containers=off,`that would force Python into legacy mode. There is a file, `EXTERNALLY-MANAGED`, that you should be deleting upon container creation if you want to be able to install stuff within. See the [docs](https://packaging.python.org/en/latest/specifications/externally-managed-environments/). ---
**Author:** ![jharris1993](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/jharris1993/32/37747_2.png) [@jharris1993](https://discuss.python.org/u/jharris1993)\ **Post date:** [October 5, 2026, 7:40am UTC](https://discuss.python.org/t/add-a-global-switch-to-disable-the-container-requirement/109335/5 "2026-10-05T07:40:02Z")
What I want to do is globally disable containers. ---
**Author:** ![jonathandung](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/jonathandung/32/35459_2.png) [@jonathandung](https://discuss.python.org/u/jonathandung)\ **Post date:** [October 5, 2026, 10:31am UTC](https://discuss.python.org/t/add-a-global-switch-to-disable-the-container-requirement/109335/6 "2026-10-05T10:31:39Z")
Docker containers? ---
**Author:** ![DavidCEllis](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/davidcellis/32/9789_2.png) [@DavidCEllis](https://discuss.python.org/u/DavidCEllis)\ **Post date:** [October 5, 2026, 12:12pm UTC](https://discuss.python.org/t/add-a-global-switch-to-disable-the-container-requirement/109335/7 "2026-10-05T12:12:33Z")
I’m a little confused here, I think you have the purpose of this error backwards? The error is not for containers, it’s for the regular operating system to prevent `pip` from installing packages in the system python environment and breaking applications installed through the system package manager (in some cases breaking the system package manager itself). A virtual environment doesn’t have the same level of separation as a container. With `--system-site-packages` it will even be able to use libraries installed through the system package manager. If you need to access hardware _and_ need to install additional libraries for your script this should be fine. If you still want to install into the system environment with `pip` and aren’t concerned about potentially\[1\] breaking applications the system relies upon and are happy to handle fixing the system or starting from a fresh image if it does end up broken I believe you should be able to set the environment variable [`PIP_BREAK_SYSTEM_PACKAGES`](https://pip.pypa.io/en/stable/cli/pip_install/#cmdoption-break-system-packages), there may also be some other ways to configure pip to ignore the restriction. I would strongly recommend against doing so though. * * * 1. You might be fine, but no guarantees. ---
**Author:** ![jharris1993](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/jharris1993/32/37747_2.png) [@jharris1993](https://discuss.python.org/u/jharris1993)\ **Post date:** [October 5, 2026, 12:50pm UTC](https://discuss.python.org/t/add-a-global-switch-to-disable-the-container-requirement/109335/8 "2026-10-05T12:50:54Z")
The problem isn’t that containers are bad _per se_, the problem is that containers aren’t a panacea, they’re not a silver bullet. I am saying that there are situations that exist outside the normal baseline. As I said before, the “normal” situation is a stand-alone application on an independent system like Windows or Linux Mint. There are systems, smaller systems, more constrained systems, where the Python installation IS the system - and where a container is more trouble than it’s worth. All I’m asking for is a way to re-enable the legacy behavior in those situations where it’s necessary. ---
**Author:** ![DavidCEllis](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/davidcellis/32/9789_2.png) [@DavidCEllis](https://discuss.python.org/u/DavidCEllis)\ **Post date:** [October 5, 2026, 1:17pm UTC](https://discuss.python.org/t/add-a-global-switch-to-disable-the-container-requirement/109335/9 "2026-10-05T13:17:33Z")
Again, this **does not require a container** , I’m not suggesting you create a full container for this. A virtual environment is not the same as a docker or podman container. When created it’s a ~13M folder, almost all of which is a copy of `pip`. The “old behaviour” was that you could break things and we didn’t warn you about it or try to stop you\[1\]. You can go back to this behaviour on `pip` with configuration as I mentioned before, but I’d still recommend against it if possible. * * * 1. There wasn’t a standard mechanism, distros may have modified `pip` or used some other mechanism to try to prevent you from doing so but no guarantees.