5 ms·

Odd to me that you don’t let poetry create the venv? Why do this separately? Our flow is similar: pyenv (windows and linux), pipx, poetry. We’ve also defaulte

by p33p 2y ago

Odd to me that you don’t let poetry create the venv? Why do this separately? Our flow is similar: pyenv (windows and linux), pipx, poetry. We’ve also defaulted poetry to utilize the current global version of Python and build the venv within the project folder.

lexicality 2y ago
Personally I've had problems with poetry managing virtualenvs in the past so I just don't let it touch them any more. Maybe it's better now, but I don't see any reason to risk it, given how often Python seems to like to ruin my day. I also don't like that by default it wants you to use `poetry run` to run things. Sure you can configure it not to, but it still annoys me
- Hackbraten 2y ago
  One issue I’ve been encountering is that Poetry isn’t aware of pyenv or `.python-version`. So what I do to initially build my venv is: pyenv exec pip install poetry && pyenv exec poetry install This creates the venv against the correct Python version, and I can now do without `pyenv exec` for this repository. And every time that `.python-version` changes (which I at most do a few times per year per project,) I throw away the `.venv`, do `pyenv install -s` and start over. Your `poetry run` point still stands, though.
  - 0x008 2y ago
    Now you have poetry installed for every version of python and need to keep track of updating all of those poetry installs. Python really makes things difficult :D
    - Hackbraten 2y ago
      > Now you […] need to keep track of updating all of those poetry installs. You’re absolutely right. On second thought, I guess I only need these Poetry installs just once anyway: for creating the venv and then never again. That’s not worth it. So here’s a new method that does away with these extra Poetry installs: pyenv exec python -m venv .venv && poetry install assuming that a `poetry.toml` exists with `virtualenvs.in-project` set to `true`. Going to adopt this variant from now on, I guess. Thank you for your thoughts!
  - deleted 2y ago
    [deleted]

by p33p 2y ago

lexicality 2y ago

Personally I've had problems with poetry managing virtualenvs in the past so I just don't let it touch them any more. Maybe it's better now, but I don't see any reason to risk it, given how often Python seems to like to ruin my day. I also don't like that by default it wants you to use `poetry run` to run things. Sure you can configure it not to, but it still annoys me

Hackbraten 2y ago
One issue I’ve been encountering is that Poetry isn’t aware of pyenv or `.python-version`. So what I do to initially build my venv is: pyenv exec pip install poetry && pyenv exec poetry install This creates the venv against the correct Python version, and I can now do without `pyenv exec` for this repository. And every time that `.python-version` changes (which I at most do a few times per year per project,) I throw away the `.venv`, do `pyenv install -s` and start over. Your `poetry run` point still stands, though.
- 0x008 2y ago
  Now you have poetry installed for every version of python and need to keep track of updating all of those poetry installs. Python really makes things difficult :D
  - Hackbraten 2y ago
    > Now you […] need to keep track of updating all of those poetry installs. You’re absolutely right. On second thought, I guess I only need these Poetry installs just once anyway: for creating the venv and then never again. That’s not worth it. So here’s a new method that does away with these extra Poetry installs: pyenv exec python -m venv .venv && poetry install assuming that a `poetry.toml` exists with `virtualenvs.in-project` set to `true`. Going to adopt this variant from now on, I guess. Thank you for your thoughts!
- deleted 2y ago
  [deleted]