extend python-venv.* to deal with poetry projects

[jhheider]

more and more projects are migrating to poetry, which doesn't have a clean --prefix style syntax. there are a number of possibilities, but they're all a touch awkward: python-poetry/poetry#1937

given this, we get the following for gpt-engineer:

    # https://github.com/python-poetry/poetry/issues/1937#issuecomment-983754739
    - run: |
        poetry config virtualenvs.create true
        poetry config virtualenvs.in-project true
        poetry install --with=experimental
        poetry build -f sdist
        tar zxvf dist/gpt_engineer-{{version}}.tar.gz -C .venv/lib/python3.11/site-packages --strip-components=1
        mkdir -p "{{prefix}}"
        export VIRTUAL_ENV="{{prefix}}/venv"
        cp -a .venv "$VIRTUAL_ENV"
        python-venv-stubber.sh gpt-engineer
      if: '>=0.2.1'

since this is fairly boiler-platey (only --with=experimental is custom to gpt-engineer) it might be worth packaging into our existing scripts. it could be handled in two flags:

- --use-poetry
- --additional-install-args="string"

maybe we don't want the clutter, but i expect to see this more and more.

[jhheider]

hm, even that's not the final form; but it's getting closer.

[jhheider]

final form above. that was just annoying to figure out.

[mxcl]

thanks J I'll see about adding this

[mxcl]

Something doesn't work right for my fixture, you can see the virtual env that poetry constructs is non standard (_internal and _vendor dirs)

However, it works fine for GPT Engineer. So I’m looking for differences between my fixture and it that seem to control that behavior.

https://github.com/pkgxdev/brewkit/actions/runs/7395991058/job/20120257509?pr=254

[jhheider]

There Must Be A Better Way™

time to write a python compiler in rust, probably.

[mxcl]

oh actually my mistake, I was misreading the output