Thanks for all the responses but it seems an alternate solution presented by another user in a direct reply is to use python3 - m venv. Basically using the venv built in to python3 as opposed to the legacy method of py-virtualenv that I typically only have to use for older python 2 code bases.
Thanks all for the replies. Ken On Mon, Apr 30, 2018 at 06:23:32PM -0400, Dave Voutila wrote: > 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