Ken MacKenzie <k...@mack-z.com> writes: > Is there a recommended best practice when setting up an environment with > python > virtualenv with regards to wxallowed.
AFAIK nothing official. > > My typical workflow is under my home directory I have a > dev/language/project/.venv type structure. I guess the simple solution is to > mount /home as wxallowed in /etc/fstab, but is that truly the preferred way. > Seems to make a new attack surface for anything in home. > Turning off any default mitigations is probably the opposite of "preferred". > The other option I am thinking is to create a dev-username location in > /usr/local somewhere and then ln -s that into my home structure accordingly. > > Since I am new to OpenBSD I figured I would ask first and did not find much > on > this topic other than third parties that seem to want to casually just add > home > to wxallowed. > I've been too lazy to dig into and "fix" this in the py{2,3}-virtualenv port. The main issue is it copies the binary for the target python executable and doesn't symlink it. It's really not a bug and more an adaptation issue so I've not been inclined. However, symbolic links to /usr/local/bin/python work fine if they're located on partitions that aren't mounted wxallowed. I'd imagine if virtualenv created a symlink things would "just work." So what I do, instead of teaching virtualenv to symlink instead of copy, is just confine my virtualenvs to /usr/local/venv (owned by root:wsrc). I then just activate via the usual means of the activate script: kogelvis$ . /usr/local/venv/my-project/bin/activate Typically, on other systems, I'd locate it in ~/.venv but for my personal machine it's not an issue. I do set an environment variable: WORKON_HOME=/usr/local/venv in .profile so I can configure tools like emacs major modes to point to where I want them to create/find virtual environments. > Thanks in advance for any guidance, > > Ken