Error with pip3 install -e evennia

109 views
Skip to first unread message

Samuel Wiswell

unread,
Feb 17, 2021, 4:05:53 PM2/17/21
to Evennia
I'm trying to get Evennia up and running on a Pi4 with Raspberry OS. Everything always defaults to python 2.7 so I'm using pip3 and I receive this error when executing pp3 install -e evennia. 

   running develop
    WARNING: The user site-packages directory is disabled.
    error: can't create or remove files in install directory
    
    The following error occurred while trying to add or remove files in the
    installation directory:
    
        [Errno 13] Permission denied: '/usr/lib/python3.7/site-packages'
    
    The installation directory you specified (via --install-dir, --prefix, or
    the distutils default setting) was:
    
        /usr/lib/python3.7/site-packages/
    
    This directory does not currently exist.  Please create it and try again, or
    choose a different installation directory (using the -d or --install-dir
    option).
    
    
    ----------------------------------------
Command "/usr/bin/python3 -c "import setuptools, tokenize;__file__='/home/pi/muddev/evennia/setup.py';f=getattr(tokenize, 'open', open)(__file__);code=f.read().replace('\r\n', '\n');f.close();exec(compile(code, __file__, 'exec'))" develop --no-deps --user --prefix=" failed with error code 1 in /home/pi/muddev/evennia/

I'm fairly new to using python in linux but it's something I wanted to tackle as a hobby. If I'm doing this completely wrong feel free to point me in the correct direction. So far I've been able to solve every problem before now. Thank you for any help you can provide.
P.S. I tried installing Evannie in windows but that was a complete mess.

Quilnux

unread,
Feb 17, 2021, 4:08:47 PM2/17/21
to Evennia
It's telling you to create a directory at the location it specified in the error, have you done that yet?

I'm not running Evennia on linux (Windows here)  at the moment but this error has come up before with pip and each time it's happened for me, I've always just created the directory and ensured the permissions were set correctly. Reran the command and it just worked.

Griatch Art

unread,
Feb 17, 2021, 4:11:04 PM2/17/21
to Evennia
Sounds like you are trying to install without activating your virtualenv.

CivilS4m

unread,
Feb 17, 2021, 4:24:15 PM2/17/21
to Evennia
Hi, I do have the evennia and evenv directories created and I am in muddev when I run the source to enter virtualenv which then puts me in evenv. You can see that process bellow. Or did you mean that I need to make the usr/lib/python3.7/site-packages directory? Let me know if I'm doing something wrong here. 

pi@raspberrypi:~ $ cd muddev
pi@raspberrypi:~/muddev $ dir
evennia  evenv
pi@raspberrypi:~/muddev $ source evenv/bin/activate
(evenv) pi@raspberrypi:~/muddev $ pip3 install -e evennia

CivilS4m

unread,
Feb 17, 2021, 5:08:44 PM2/17/21
to Evennia
Thank you so much for the help guys and or gals! These suggestions helped me dig a little further into what was going on and I had to run it as sudo. as I said I am new to Linux and set this all up under the pi folder with the little red house on the folder. Is this the root directory and if so, was this bad practice on my part which is why I had to use sudo to override the protections of the root directory? 

Griatch Art

unread,
Feb 17, 2021, 5:36:35 PM2/17/21
to Evennia
Normally you should not run Evennia as root and you should not need to use sudo to install anything in your virtualenv. When you install with your virtualenv, the path it installs to will be in your evenv/ and not under /usr/lib/ like the error you had. So not sure why it would do that if you had set up the virtualenv correctly.
So in summary - no it's not good practice to have to use sudo/root for Evennia. If your game is not open to the outside world it's probably not a big deal, but if it is, it's a potential security issue.
.
Griatch

Quilnux

unread,
Feb 17, 2021, 6:45:02 PM2/17/21
to Evennia
So what does VirtualEnv do exactly if I may ask? In Windows VirtualEnv isn't supported so I skipped that step on mine.

Griatch Art

unread,
Feb 17, 2021, 6:49:56 PM2/17/21
to Evennia
Virtualenv is most certainly supported on Windows? Here is a summary of what a virtualenv is, from our docs: https://www.evennia.com/docs/latest/Glossary.html#virtualenv

Quilnux

unread,
Feb 17, 2021, 6:58:14 PM2/17/21
to Evennia
Sorry, I'll qualify my statement, it's not supported without installing WSL which I really prefer not to do.

Griatch Art

unread,
Feb 18, 2021, 2:10:17 AM2/18/21
to Evennia
You should be able to install virtualenv with `pip`, it should not matter if you are on 'plain' Windows or Windows WSL or Linux or Mac etc ... do you have any reference as to virtualenv being a no-go on plain Windows?
.
Griatch

Quilnux

unread,
Feb 18, 2021, 3:09:44 PM2/18/21
to Evennia
Other then the fact that pip automatically force installs WSL on my Windows 10 machine (which gets blocked by a GP) during the install of virtualenv, no. Most of the links online talk about it though and say that for most installs of virtualenv, you need to have WSL installed or problems will arise. Only exception to this is Python 3.7 from Windows Store, which has a modified version of Virtualenv that works without WSL. I tried installing it manually without using pip to see if I could get it to install and run without WSL and while it did install, the moment I tried to run it, the GP popped up and said "VirtualEnv is trying to install Windows Subsystem Linux but was blocked due to group policy. Please contact your administrator for support" which is actually me since I explicitly blocked WSL from installing.

In the last day or two since we've been talking about it, I took a look into more details about it and from what I'm looking at it just allows you to isolate multiple versions of Python on your system. So if you only have 1 version installed, and don't plan to run multiple versions side-by-side the VirtualEnv isn't required. As far as app-isolation, Windows 10 does that by default now anyways in the 2004 update so it's probably not even required for that at this point unless you are running an older version of Windows 10. Since I only have Python installed for Evennia, I decided to run it without virtualenv and it seems to be working perfectly without it. So it seems, at least on Windows, it's optional. I won't speak for Evennia on linux because that might be a different story.

Griatch Art

unread,
Feb 18, 2021, 3:15:49 PM2/18/21
to Evennia
No, virtualenv isolates *python packages* (see our page on it), as well as python versions into separate environments. It's correct that it's optional (both on Linux and Windows). But it's generally recommended since it allows for experimentation with versions without affecting other python packages on the same system. It also allows you to install and run python packages without admin/root privileges.
.
Griatch

Quilnux

unread,
Feb 18, 2021, 3:39:50 PM2/18/21
to Evennia
The VirtualEnv web site said it can be used to isolate both python versions and python packages so I'm just going off of their web site. I didn't need admin rights or permissions to install anything related to evennia so as far as I can tell it wasn't really needed. Only thing I needed admin rights for was to install python itself. I'm assuming virtualenv cannot be installed without python so you'll still need admin rights for that. But afterwards pip never asked for elevation on windows 10 and I haven't had any issues with other players connecting to evennia so it doesn't need to care if it's running as admin or user-mode.

But as I said before, I was just asking about VirtualEnv since I skipped the step when it tried to install WSL and since it worked right I didn't give it much mind after that. Wasn't planning to get into a back and forth argument over it when I inquired so forgive me for asking.

Back to your regularly scheduled programming! Have a good one!

Griatch Art

unread,
Feb 19, 2021, 5:10:21 AM2/19/21
to Evennia
It's not a debate, I'm just curious as to the installation behaviour on Windows :)
.
Griatch

Quilnux

unread,
Feb 19, 2021, 10:36:10 AM2/19/21
to Evennia
The internet makes it hard to discern tone...

I've been very interested in this topic since finding out about the WSL thing with VirtualEnv. I actually spent a lot of time yesterday (more than I would like to admit) trying to understand the WSL component to VirtualEnv. Even for me, it did seem odd to need that installed considering what it actually does. What exact role does WSL play in it? Windows does have it's own version and set of APIs that do the same thing as VirtualEnv and for Python not to utilize those is a bit surprising considering the Python interpreter does use a lot of Windows-native API's when processing code interpretation.

Here's what I figured out.

WSL has two versions. Version 2 is basically a VM running Linux (I am not blocking this version). The only difference between it and Hyper-V is the fact that the OS operates it without the need for user intervention during setup as is required with Hyper-V. WSLv2 uses Hyper-V directly so those components are required to function. WSL version 1 is an isolated container that runs a specialized driver that converts all Linux kernel calls to Windows kernel calls. calls are then executed on the Windows kernel. There is a special isolation layer involved which separates the Windows and Linux execution environments.

Windows also has a built-in isolation component called AppContainer which isolates an application in many ways similar to VirtualEnv. The only difference (other than API and code) between AppContainer and VirtualEnv is that AppContainer has more isolation capabilities then VirtualEnv. From what I can tell, VirtualEnv does Process isolation (which allows multiple versions of Python to be installed and running at the same time) and File Isolation (to separate dependencies and have multiple versions of dependencies running at once for different things). AppContainer does the same thing, but also adds Window Isolation (application interface), Network Isolation, Device Isolation (device resources and sensors) and Credential isolation. You can activate all of these isolation features for an application at the same time, or pick and choose which you want enabled and disabled for your application.

So it surprised me that Python didn't use this for their Windows version of VirtualEnv until I did more digging into AppContainers and the requirements for File and Process isolation. It all has to be native code (binary). Since Python is an interpreted language, AppContainers is not supported. It cannot be used with interpreters because of how it functions.

So this leaves Python with only one other option, WSL. Now I get to the part where I say, this gets a little confusing because, Python does install WSLv1 while installing itself (using pip or their own manual install process which you can find on the VirtualEnv web site) but they don't install the entire WSLv1 subsystem. WSLv1 is broken down into several components. It seems to *install* and I use that loosely, 4 components of the WSLv1 subsystem. However, when running Evennia in it, it only activates 3 of the 4 WSL components. Perhaps the 4th is for something that Evennia doesn't do directly but other Python programs do. Not sure.

This leads me to the question of, why can't VirtualEnv run natively without WSL external help. So, I did a little more digging into how VirtualEnv operates. The best I can come up with is that in Linux, applications can directly control how isolation works. In Windows, the OS has to do it for the application. This means Python does not have direct control over how it works. Additionally, the way Windows isolation works, it wouldn't allow multiple dependencies to operate in isolation while allowing them to be accessible externally to other python applications, not without AppContainer and not without native binaries. WSLv1 allows for python to bypass this since WSLv1 is a trusted component of windows. (this is also why I block it.)

This was a very interesting rabbit hole to fall into.

I have oversimplified a few explanations for reduced brevity of this post.

Griatch Art

unread,
Feb 21, 2021, 10:40:50 AM2/21/21
to Evennia
Virtualenv is, despite the name, not a virtual environment in the expected sense. It is not concerned with security per se, only with Python package versioning. All it really does is to set up the envvars to have the `python` command point to the python binary you want to use and then set the PYTHON_PATH envvar to root all `pip` and package lookups to a location within the folder one assigns for it. It means that you can then do `pip install X` and stuff will end up in that folder rather than being globally installed. It doesn't care at all about non-python things - if you were to use e.g. Python's subprocess call to execute a non-python program from inside your python script. that should work just fine for example.

I agree it's strange that Virtualenv should require WSL - virtualenv has worked just fine in older versions of Windows (long before WSL was a thing). So maybe this is some new thing. I'll take a look at testing it when I next get my hand on a Windows10 install. Thanks for spending the time to analyze things!
.
Griatch

Quilnux

unread,
Feb 21, 2021, 12:09:24 PM2/21/21
to Evennia
Since the PYTHON_PATH envvar in windows is already stored in the USER_PATH and SYSTEM_PATH I don't think you need the VirtualEnv system for that aspect. As far as pip, in an extremely hardened system, you would still need to do a UAC regardless of VirtualEnv but for the standard Windows user pip never asks for admin rights and always puts the modules in the folder I ask it to.

Microsoft made a lot of changes to Windows in v10 that were very different in versions <= 8.1 so maybe that plays a factor. I did see an article online where someone was talking about the relationship between VirtualEnv and WSL and they "claim" that without WSL installed, most of the VirtualEnv functions do not work. They say it is possible to use VirtualEnv without any WSL but you lose a lot of functionality in the process.

That being said, there is one other thing to consider. Unlike with Windows <= 8.1, Windows 10 has this new "auto-dependency resolution" system for all Windows Features installations. If an application even "hints" at having a dependency on a Windows Features component, even a soft (optional) dependency, Windows 10 will automatically install that dependency in the background without the "normal" user knowing about. Only reason I noticed was because I have a GP set up specifically to block WSL. So, it's very possible, despite my testing that WSL isn't required, but is optionally tied into WSL for additional functionality, assuming the article was correct about that. Windows 10 does a lot of things I don't like so because of that, I tend to block a lot of things, only allowing it if I manually tell it to do so myself.
Because I don't know much about VirtualEnv itself and I don't have the time to look at the source code for the Windows version, I have no idea if the WSL dependency if hard or soft. If it is hard, my guess would be that there is something specific in Windows 10 that causes VirtualEnv to fail without it. If it's a soft dependency, then Windows 10 is just installing it because VirtualEnv is pinging the system to see if it's installed or not. (kinda like how the wheel dependency is not required to install Evennia on Linux but is optional. pip will look for wheel and then probably does different things depending on if it's present or not).
Reply all
Reply to author
Forward
0 new messages