Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How Python virtual environments work

snarky.ca

Post reply on HN
Print view View original

91–100 of 293 posts

Re: How Python virtual environments work

#91

Post by rad_gruchalski »

josteink wrote: post #90

All other languages: use whatever packages you like. You’ll be fine. Python: we’re going to force all packages from all projects and repos to be installed in a shared global environment, but since nobody actually wants that we will allow you to circumvent that by creating “virtual” environments you can maintain and have to deal with instead. Also remember to activate it before starting your editor or else lulz. And d…

Yeah, how does it go? There’s at least one obvious way to do something? Python… makes me anxious. I don’t mind writing Python but setting it up is crazy.

Re: How Python virtual environments work

#93

Post by fiddlerwoaroof »

okeuro49 wrote: post #81
adgjlsfhk1 wrote: post #71

Earlier quoted context omitted.

Yeah, one of Julia's best decisions was taking heavy inspiration from Rust for the package manager. Rust was 100% the first language to get dependency management right.

> Rust was 100% the first language to get dependency management right. In my experience, Java, Go, PHP, NodeJS have all got similar package management that works.

Yeah, npm was the first good package manager. It gets a lot of hate but my experience is that its strategy is the optimal solution for the problem it solves. And, I think a lot of things people complain about (lots of trivial packages, huge dependency trees, etc.) are an effect of solving the packaging problem well: if you make it easy to add dependencies, people will take advantage of that to add lots of dependencies.

Re: How Python virtual environments work

#94

Post by wyufro »

spyremeown wrote: post #65
Havoc wrote: post #55

These days I'm just throwing each project into a fresh LXC on a server. All these different languages have their own approach and each then also user/global/multiple versions...it's just not worth figuring out

Question: what makes you choose LXC over Docker?

IMO, while their use cases do overlap, LXC is more geared towards a user installing things while Docker is more geared towards a developer creating a ready to use package.

LXC creates environments, while Docker creates apps, is another way to say it.

Re: How Python virtual environments work

#95

Post by insane_dreamer »

buildbot wrote: post #63

I personally hate Conda with a firey passion - it does so much weird magic and ends up breaking things in non obvious ways. Python works best when you keep it really simple. Just a python -m venv per project, a requirements.txt, and you will basically never have issues.

I'm the opposite. We have to maintain a lot of different environments for different projects, and with conda things "just work" (esp now with better PyCharm integration). Venv is much more of a hassle.

Re: How Python virtual environments work

#96

Post by Groxx »

aflag wrote: post #73
_coveredInBees wrote: post #67

I'm surprised at the number of people here complaining about venvs in Python. There are lots of warts when it comes to package management in Python, but the built-in venv support has been rock solid in Python 3 for a long time now. Most of the complaints here ironically are from people using a bunch of tooling in lieu of, or as a replacement for vanilla python venvs and then hitting issues associated with those tools…

It's incredibly lacking in features. PyPI doesn't even properly index packages, making pip go into this dependency resolution he'll trying to find a set of versions that will work for you. It works for simple cases with few dependencies/not a lot of pinning. But if your needs are a bit more complex it certainly shows its rough edges. I actually find it amazing that they python community puts up with that. But I suppo…

What does that have to do with venvs?

I agree the packaging and distribution setup in python is an absolute mess, but that's entirely unrelated to venvs. It's like bringing up how python uses whitespace instead of curly-braces.

Re: How Python virtual environments work

#97

Post by 9dev »

_coveredInBees wrote: post #67

I'm surprised at the number of people here complaining about venvs in Python. There are lots of warts when it comes to package management in Python, but the built-in venv support has been rock solid in Python 3 for a long time now. Most of the complaints here ironically are from people using a bunch of tooling in lieu of, or as a replacement for vanilla python venvs and then hitting issues associated with those tools…

Oh, yeah? It’s working great? Like figuring out which packages your application actually uses? Or having separate development and production dependencies? Upgrading outdated libraries?

Having taken a deep-dive into refactoring a large python app, I can confidently say that package management in python is a pain compared to other interpreted languages.

Re: How Python virtual environments work

#98

Post by rowanseymour »

9dev wrote: post #97
_coveredInBees wrote: post #67

I'm surprised at the number of people here complaining about venvs in Python. There are lots of warts when it comes to package management in Python, but the built-in venv support has been rock solid in Python 3 for a long time now. Most of the complaints here ironically are from people using a bunch of tooling in lieu of, or as a replacement for vanilla python venvs and then hitting issues associated with those tools…

Oh, yeah? It’s working great? Like figuring out which packages your application actually uses? Or having separate development and production dependencies? Upgrading outdated libraries? Having taken a deep-dive into refactoring a large python app, I can confidently say that package management in python is a pain compared to other interpreted languages.

Virtual environments aren't package management. For example we use Poetry for package management - it supports separate dev and prod dependencies, upgrading etc. It generates a virtual environment.

Re: How Python virtual environments work

#99

Post by billforsternz »

dwringer wrote: post #26
swyx wrote: post #10

Earlier quoted context omitted.

also there's like 3 different flavors of virtual env now and me being 8 years out of date with my python skillz i have no idea what the current SOTA is with python venv tooling :/ i dont need them demystified, i need someone smarter than me to just tell me what to do lol

> and me being 8 years out of date with my python skillz i have no idea what the current SOTA is with python venv tooling :/ It doesn't really matter, by the time you sit down and use it you'll find whatever that is, has also been deprecated and replaced by 2 more.

The problem with software development in 2023 in a nutshell, well played sir.

Re: How Python virtual environments work

#100

Post by oneepic »

Groxx wrote: post #96
aflag wrote: post #73

Earlier quoted context omitted.

It's incredibly lacking in features. PyPI doesn't even properly index packages, making pip go into this dependency resolution he'll trying to find a set of versions that will work for you. It works for simple cases with few dependencies/not a lot of pinning. But if your needs are a bit more complex it certainly shows its rough edges. I actually find it amazing that they python community puts up with that. But I suppo…

What does that have to do with venvs? I agree the packaging and distribution setup in python is an absolute mess, but that's entirely unrelated to venvs. It's like bringing up how python uses whitespace instead of curly-braces.

I think the GP comment might have caused some confusion since it mentioned both package management and venvs very close together.
Post reply on HN