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
