build failing when python3.11-venv is not installed

[jugmac00]

While testing the release candidate for tox (tox -e py311), I ran into this exception:

build/src/build/env.py

Line 274 in 656c487

raise build.FailedProcessError(exc, 'Failed to create venv. Maybe try installing virtualenv.') from None

But I had virtualenv already installed (in a globally available virtualenv, not a system package). The solution was to install python3.11-venv instead.

I am on Ubuntu 20.04 with Python 3.11 installed via deadsnakes PPA.

[layday]

Builds run in an isolated environment without access to system site packages, which is why build was not able to locate virtualenv. venv is part of the stdlib, albeit debundled by Debian.

[jugmac00]

@layday Thanks for clarifying. Do you think it makes sense to update the exception message to point out what to do on Debian/Ubuntu?

[layday]

I think my original diagnosis was incorrect. Was build installed in the same environment as virtualenv, and which version of virtualenv did you have?

[jugmac00]

virtualenv is version 20.13.0 (hu, have not updated for a while), and yes, it is installed in a separate virtualenv (bootstrapped as a zipapp).

build was installed via tox for a test

@pytest.mark.usefixtures("enable_pip_pypi_access")
def test_build_wheel_external(tox_project: ToxProjectCreator, demo_pkg_inline: Path) -> None:
    ini = """
    [testenv]
    package = external
    package_env = .ext
    commands =
        python -c 'from demo_pkg_inline import do; do()'

    [testenv:.ext]
    deps = build
    package_glob = {envtmpdir}{/}dist{/}*.whl
    commands =
        pyproject-build -w . -o {envtmpdir}{/}dist
    """
    project = tox_project({"tox.ini": ini})
    result = project.run("r", "--root", str(demo_pkg_inline))

    result.assert_success()
    assert "greetings from demo_pkg_inline" in result.out

[layday]

Alright, then I assume that virtualenv was (indeed) not available inside the tox env; I'd still recommend requiring virtualenv (i.e. build[virtualenv]) if it works.

[uranusjr]

Would it make sense to add a virtual environment creation method to use the virtualenv command in PATH alongside with existing methods?

[layday]

Possibly, although IIUC virtualenv is not on path in the scenario described. Sent with [Proton Mail](https://proton.me/) secure email.

…

------- Original Message -------

On Monday, December 12th, 2022 at 07:00, Tzu-ping Chung ***@***.***> wrote: Would it make sense to add a virtual environment creation method to use the virtualenv command in PATH alongside with existing methods? — Reply to this email directly, [view it on GitHub](#548 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AHNRFWB5OMAV5MFBITVCYW3WM2WORANCNFSM6AAAAAASVQKGQ4). You are receiving this because you were mentioned.Message ID: ***@***.***>