Opened 8 years ago

Last modified 7 years ago

#5064 new defect

Add option to override ./configure'd virtualenv

Reported by: ayleph Owned by:
Priority: trivial Milestone:
Component: programming Keywords: virtualenv, configure
Cc: Parent Tickets:


./configure searches for virtualenv in the following order:

  • virtualenv
  • virtualenv3
  • virtualenv2

Once a match is found, the search terminates. If a user has both python2 and python3 installed, then the python3 virtualenv may be configured for use, even when --with-python3 is not specified. This results in an error for users who intend to use (or need to use) python2.

In the case of Arch Linux, virtualenv is the python3 package, and virtualenv2 is the python2 package. When I run ./configure without specifying --with-python3, the python3 virtualenv is configured even though I didn't intend to use python3. To fix this, I must manually edit Makefile as follows before running make.

-VIRTUALENV = virtualenv
+VIRTUALENV = virtualenv2

Some options for how to deal with this come to mind.

Does ./configure support interactive configuration? If so, we could consider searching for all virtualenvs and then asking the user which one they want to use.

The undocumented --with-virtualenv switch [1] could be extended to accept a path to the desired executable.

If distributions consistently use virtualenv2 for python2 and use virtualenv (or virtualenv3) exclusively for python3, perhaps we could tie the selection of virtualenv to the python version specified in configuration.

[1] --with-virtualenv is a programmed option in ./configure, but it isn't shown in ./configure --help. See issue #5022.

Change History (3)

comment:1 by Christopher Allan Webber, 8 years ago

Priority: majortrivial

It would be nice to be able to set the virtualenv command, I agree. I'll look into this for the release, but I think it's low priority comparatively.

comment:2 by Christopher Allan Webber, 8 years ago


Moving this to 0.9.0

comment:3 by Christopher Allan Webber, 7 years ago

Milestone: 0.9.0

This is a defect probably, but not important enough to delay this release. I'm removing this from the milestone.

Note: See TracTickets for help on using tickets.