4 ms·

As OP suggests, you can ignore basically all of it. If you're just messing around, use your system Python. That'll get you a long way. If you're Starting A Proj

As OP suggests, you can ignore basically all of it. If you're just messing around, use your system Python. That'll get you a long way. If you're Starting A Project and want to install packages locally, use the virtualenv package that came with your system Python. That's gotten me through basically all my Python programming for 15 years. Anything more complicated than that, you can learn when you come to it.

dns_snek 4y ago
> If you're Starting A Project and want to install packages locally, use the virtualenv package that came with your system Python. I think this should be emphasized more, I don't think it's just a matter of preference, not separating packages between projects using virtualenvs will land you in a world of hurt as soon as you want to update or uninstall any of them and they're hopelessly entangled with system packages and other projects.
- andrewflnr 4y ago
  If you're just starting with the language though, you might only have one project for a long time, or your projects might have disjoint dependencies (or close enough; I'm imagining someone with both a Django and pygame project). And you can learn a lot without any libraries at all. As a teen, I went a couple years and learned a lot before I learned how to use virtualenv. You'll want it sooner, but it absolutely shouldn't be a barrier to getting your feet wet.
  - dns_snek 4y ago
    That's certainly valid, if someone is just getting started like you say then it's not something they should worry about. I wasn't thinking of complete beginners when I wrote that comment.
nerpderp82 4y ago
> use your system Python. Maybe you are an accidental accelerationist? Using the system Python is fastest way to a broken system and a broken Python.
- Filligree 4y ago
  God save people who don't know you're 'supposed' to use something else. Most projects state something like "run pip install whatever", which people will then do. If you're lucky, it will ask for sudo. If you're even luckier, you stop to think before entering your password.
  - nerpderp82 4y ago
    I have a default Python env that my shell sources for every login shell. I can deactivate it and activate different envs on a per project basis. That default Python env means I don't ever modify the system python for any reason. I type `python` and I get my own Python3 from the base.env If you use homebrew, there are two settings that help keep your old python binaries around so that venvs that reference those old envs don't break. HOMEBREW_NO_CLEANUP_FORMULAE, this takes a lists of packages to not cleanup HOMEBREW_NO_INSTALL_CLEANUP, prevents old packages from getting removed
  - deaddodo 4y ago
    Node has the exact same issue for people who globally install all packages. The only differences are A) python makes environment management the dev's choice/responsibility and B) defaults to system vs environmental. I actually far prefer the Python method to, say, Go's GOPATH. But, I far prefer Rust/Cargo to either.
    - unscaled 4y ago
      Sure, GOPATH really sucked, but that's why we got Go Modules. I don't think it's fair to compare Python to Go anymore. I wish Python got a standard integrated solution for package management that works. pip doesn't cut it in my book since it doesn't let you specify dependencies reproducibly. It either doesn't support lockfiles or ONLY supports having a lockfile, without dependencies. venv also doesn't cut it since you have to remember to explicitly activate it and keep track of which venv is activated right now. If we take a look at the much-maligned Node.js+npm, it's still far better than what built-in tools in Python let you have. Yes, Node.js doesn't provide full isolation from globally-installed node_modules, but at least it supports a local node_modules directory and lets it take preference. Notably Node.js+npm, with all its warts, doesn't suffer from the the two issues I've mentioned above.

dns_snek 4y ago

> If you're Starting A Project and want to install packages locally, use the virtualenv package that came with your system Python. I think this should be emphasized more, I don't think it's just a matter of preference, not separating packages between projects using virtualenvs will land you in a world of hurt as soon as you want to update or uninstall any of them and they're hopelessly entangled with system packages and other projects.

andrewflnr 4y ago
If you're just starting with the language though, you might only have one project for a long time, or your projects might have disjoint dependencies (or close enough; I'm imagining someone with both a Django and pygame project). And you can learn a lot without any libraries at all. As a teen, I went a couple years and learned a lot before I learned how to use virtualenv. You'll want it sooner, but it absolutely shouldn't be a barrier to getting your feet wet.
- dns_snek 4y ago
  That's certainly valid, if someone is just getting started like you say then it's not something they should worry about. I wasn't thinking of complete beginners when I wrote that comment.

nerpderp82 4y ago

> use your system Python. Maybe you are an accidental accelerationist? Using the system Python is fastest way to a broken system and a broken Python.

Filligree 4y ago
God save people who don't know you're 'supposed' to use something else. Most projects state something like "run pip install whatever", which people will then do. If you're lucky, it will ask for sudo. If you're even luckier, you stop to think before entering your password.
- nerpderp82 4y ago
  I have a default Python env that my shell sources for every login shell. I can deactivate it and activate different envs on a per project basis. That default Python env means I don't ever modify the system python for any reason. I type `python` and I get my own Python3 from the base.env If you use homebrew, there are two settings that help keep your old python binaries around so that venvs that reference those old envs don't break. HOMEBREW_NO_CLEANUP_FORMULAE, this takes a lists of packages to not cleanup HOMEBREW_NO_INSTALL_CLEANUP, prevents old packages from getting removed
- deaddodo 4y ago
  Node has the exact same issue for people who globally install all packages. The only differences are A) python makes environment management the dev's choice/responsibility and B) defaults to system vs environmental. I actually far prefer the Python method to, say, Go's GOPATH. But, I far prefer Rust/Cargo to either.
  - unscaled 4y ago
    Sure, GOPATH really sucked, but that's why we got Go Modules. I don't think it's fair to compare Python to Go anymore. I wish Python got a standard integrated solution for package management that works. pip doesn't cut it in my book since it doesn't let you specify dependencies reproducibly. It either doesn't support lockfiles or ONLY supports having a lockfile, without dependencies. venv also doesn't cut it since you have to remember to explicitly activate it and keep track of which venv is activated right now. If we take a look at the much-maligned Node.js+npm, it's still far better than what built-in tools in Python let you have. Yes, Node.js doesn't provide full isolation from globally-installed node_modules, but at least it supports a local node_modules directory and lets it take preference. Notably Node.js+npm, with all its warts, doesn't suffer from the the two issues I've mentioned above.