5 ms·

I've never even understood the virtual env dogma. I can see how version conflicts _could_ happen, but they never have. Admittedly, I'm surprised I never have is

by ghusto 1y ago

I've never even understood the virtual env dogma. I can see how version conflicts _could_ happen, but they never have. Admittedly, I'm surprised I never have issues installing globally, especially since others keep telling me what a terrible idea it is and how they had nightmare-scenario-X happen to them.

digisign 1y ago
I only ever had it a problem with large, poorly maintained projects from work. You know the kind that have two web frameworks required in the same project, and two orms, etc. ;-) That one I definitely put into a venv. But my stuff, no.
- not_kurt_godel 1y ago
  And then you're sunk the moment anyone else needs to run your code, or even if you just need to run your own code on another machine.
  - digisign 1y ago
    Never happened.
    - not_kurt_godel 1y ago
      I salute you for never needing a new computer, ever.
      - digisign 11mo ago
        I get a new machine most years from the business. I suggest a systems administration course if you're having so much trouble with Python libs. It can help, knowing your way around the filesystem and how to use PATHs, etc.
        not_kurt_godel 11mo ago
        Hey, good for you that you like doing things the hard, fragile way. Personally I'll stick with the natively supported python solution that was made part of the standard library precisely because the overwhelming majority of Python programmers find your approach unsatisfactory. https://peps.python.org/pep-0405/ https://peps.python.org/pep-0405/
        digisign 11mo ago
        It's not hard at all, just a pip install away. Perhaps a rare uninstall later. It sounds like you haven't read the full thread. It's common for younger developers to be slaves to "best practice" even in exceptions where it doesn't apply. Appeal to authority is not a compelling argument either.
tecoholic 1y ago
How do you work with multiple projects with different versions of the same dependencies? If you are using the “system python” for everything?
- LtWorf 1y ago
  > How do you work with multiple projects with different versions of the same dependencies? You don't… you use the same versions for everything :)
- ghusto 1y ago
  Not system Python (not least because that's a hassle to do these days anyway, with all the safeguards OS vendors have put in), but _my_ version of globally. My (user) global PyEnv version, for example. Now having said that, I suspect PyEnv is doing some voodoo behind the scenes, because I occasionally see messages like "Package X what's version N, but you have version N1". I've never investigated them though, since both old and new packages seem to work just fine regardless.
  - tecoholic 1y ago
    I see. I think your Python usage is very limited. Becaue even when I was using Pyenv, I still needed pyenv-virtualenv to make sure my repositories didn't cross install different chain of dependencies into the same version.
electroglyph 1y ago
it's very common for different projects to have different requirements, especially for fast moving libraries like transformers. if you rarely run python stuff it might not be a big deal, but i'd rather not have to reinstall stuff (especially big stuff like pytorch builds) every time i switch projects.
- kstrauser 1y ago
  That's exactly it. Imagine your company has multiple Python repos, and one depends on foo>=1.0,<2.0, and another depends on foo>=2.0. Venvs let you configure completely isolated environments for each so that they can peacefully coexist. I would not for a moment consider using Python without virtualenvs, though I'm not opinionated about which tool manages them. Uv? Great. Poetry? Fine. `python -m venv`? Whatever. They all get the job done. Honestly, I can't think of a single good reason not to want to use a venv for Python.
  - LtWorf 1y ago
    Using the same version of everything lets you have a much easier time when a vulnerability is discovered?
    - kstrauser 1y ago
      How so? That hasn’t been my experience.
      - LtWorf 1y ago
        Do you monitor CVEs?
esseph 1y ago
They happen /all the time/. For a long time there were even compatibilities between the RHEL host python version, and the python version the Red Hat Ansible team were shipping.
- ghusto 1y ago
  > They happen /all the time/. So I keep hearing ;) Meanwhile, on my machines ...
  - esseph 1y ago
    Sure, but if you manage a diverse fleet of apps that could be a decade or two old across thousands of servers, some of those being python projects, you really quickly can run into issues between host and application.
selcuka 1y ago
I write Python code for a living and no two projects I work on have the exact same dependencies. This is especially true when working with microservices, or working for multiple customers.

by ghusto 1y ago

digisign 1y ago

I only ever had it a problem with large, poorly maintained projects from work. You know the kind that have two web frameworks required in the same project, and two orms, etc. ;-) That one I definitely put into a venv. But my stuff, no.

not_kurt_godel 1y ago
And then you're sunk the moment anyone else needs to run your code, or even if you just need to run your own code on another machine.
- digisign 1y ago
  Never happened.
  - not_kurt_godel 1y ago
    I salute you for never needing a new computer, ever.
    - digisign 11mo ago
      I get a new machine most years from the business. I suggest a systems administration course if you're having so much trouble with Python libs. It can help, knowing your way around the filesystem and how to use PATHs, etc.
      - not_kurt_godel 11mo ago
        Hey, good for you that you like doing things the hard, fragile way. Personally I'll stick with the natively supported python solution that was made part of the standard library precisely because the overwhelming majority of Python programmers find your approach unsatisfactory. https://peps.python.org/pep-0405/ https://peps.python.org/pep-0405/
        digisign 11mo ago
        It's not hard at all, just a pip install away. Perhaps a rare uninstall later. It sounds like you haven't read the full thread. It's common for younger developers to be slaves to "best practice" even in exceptions where it doesn't apply. Appeal to authority is not a compelling argument either.

tecoholic 1y ago

How do you work with multiple projects with different versions of the same dependencies? If you are using the “system python” for everything?

LtWorf 1y ago
> How do you work with multiple projects with different versions of the same dependencies? You don't… you use the same versions for everything :)
ghusto 1y ago
Not system Python (not least because that's a hassle to do these days anyway, with all the safeguards OS vendors have put in), but _my_ version of globally. My (user) global PyEnv version, for example. Now having said that, I suspect PyEnv is doing some voodoo behind the scenes, because I occasionally see messages like "Package X what's version N, but you have version N1". I've never investigated them though, since both old and new packages seem to work just fine regardless.
- tecoholic 1y ago
  I see. I think your Python usage is very limited. Becaue even when I was using Pyenv, I still needed pyenv-virtualenv to make sure my repositories didn't cross install different chain of dependencies into the same version.

electroglyph 1y ago

it's very common for different projects to have different requirements, especially for fast moving libraries like transformers. if you rarely run python stuff it might not be a big deal, but i'd rather not have to reinstall stuff (especially big stuff like pytorch builds) every time i switch projects.

kstrauser 1y ago
That's exactly it. Imagine your company has multiple Python repos, and one depends on foo>=1.0,<2.0, and another depends on foo>=2.0. Venvs let you configure completely isolated environments for each so that they can peacefully coexist. I would not for a moment consider using Python without virtualenvs, though I'm not opinionated about which tool manages them. Uv? Great. Poetry? Fine. `python -m venv`? Whatever. They all get the job done. Honestly, I can't think of a single good reason not to want to use a venv for Python.
- LtWorf 1y ago
  Using the same version of everything lets you have a much easier time when a vulnerability is discovered?
  - kstrauser 1y ago
    How so? That hasn’t been my experience.
    - LtWorf 1y ago
      Do you monitor CVEs?

esseph 1y ago

They happen /all the time/. For a long time there were even compatibilities between the RHEL host python version, and the python version the Red Hat Ansible team were shipping.

ghusto 1y ago
> They happen /all the time/. So I keep hearing ;) Meanwhile, on my machines ...
- esseph 1y ago
  Sure, but if you manage a diverse fleet of apps that could be a decade or two old across thousands of servers, some of those being python projects, you really quickly can run into issues between host and application.

selcuka 1y ago

I write Python code for a living and no two projects I work on have the exact same dependencies. This is especially true when working with microservices, or working for multiple customers.