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

251–260 of 293 posts

Re: How Python virtual environments work

#251

Post by coldtea »

ospider wrote: post #200
coldtea wrote: post #141

Earlier quoted context omitted.

Is it "generational knowledge and battlefront experience" or just "getting used to the (shitty) way things have always been" and Stockhold Syndrome?

I don't think so. Python is battery included, and most packages in the Python ecosystem are not as scattered as npm packages. The number of packages in a typical Python project is much smaller than a Nodejs project. I think that's the reason why people are still happy with simple tools like pip and requirements.txt.

People are happy?

It's one of the major sources of disatisfaction with Python!

Re: How Python virtual environments work

#252

Post by Doxin »

pletnes wrote: post #116
zzzeek wrote: post #77

Earlier quoted context omitted.

it really is that simple conda exists because it deals with an entirely different package registry and is a whole distro on its own (I dont know why people need that either, my vague impression is that scence-y types want complete pushbutton installation, typing a command == fail, I guess, I dont know). poetry exists because it does some kind of automated version management thing (as did pipenv), that I'm sure is nic…

Before conda, you needed a C and a fortran compiler, a BLAS and LAPACK installation, and various build tools, to install scipy. Scipy is one - 1 - dependency used in science and engineering. The pain used to be massive. Now, we’re complaining about the existence of 2 high quality (not perfect) alternatives, and pip (part of the official python distro) can install tensorflow etc, GPU libs included, with a oneliner.

These days with wheels there is 0 reason why there can't be binary pip packages for any of those. Definitely used to be a problem though.

Re: How Python virtual environments work

#253

Post by nodemaker »

TheRealPomax wrote: post #204
nodemaker wrote: post #193

Earlier quoted context omitted.

Jeez just clone a venv with venv cloning tools

You mean `python -m venv`? Because that's literally that with just as little effort, and then you copy requirements.txt, but the whole point is that in 2023, this should not be necessary and the continued insistence by both python and specifically venv maintainers that it somehow needs to be this way, is insane. And telling people that they should just use clone tools is equally insane when we could just... ...you kn…

No there is a whole python module for cloning venvs.

Re: How Python virtual environments work

#254

Post by benhurmarcel »

whalesalad wrote: post #104
_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…

I've been using Python since like 2006, so maybe I just have that generational knowledge and battlefront experience... but whenever I come into threads like this I really feel like an imposter or a fish out of water. Like, am I using the same Python that everyone else is using? I echo your stance - the less overhead and additional tooling the better. A simple requirements.txt file and pip is all I need.

It's really inconvenient for simple use cases. You don't even get a command to update all packages.

Re: How Python virtual environments work

#255

Post by 9dev »

nodemaker wrote: post #253
TheRealPomax wrote: post #204

Earlier quoted context omitted.

You mean `python -m venv`? Because that's literally that with just as little effort, and then you copy requirements.txt, but the whole point is that in 2023, this should not be necessary and the continued insistence by both python and specifically venv maintainers that it somehow needs to be this way, is insane. And telling people that they should just use clone tools is equally insane when we could just... ...you kn…

No there is a whole python module for cloning venvs.

Which serves to highlight the insanity of it all? How is having a separate module for that not even worse than, as OP suggested - fixing virtual environments?

Re: How Python virtual environments work

#256

Post by 9dev »

bombolo wrote: post #238
JohnFen wrote: post #103

Earlier quoted context omitted.

Honestly, virtual environments are one of the reasons why I prefer to avoid Python whenever I can.

why? Also, you don't have to use them.

Which leaves you with what, not installing packages or sharing packages between everything on my system and all apps I work on? The 80ies just called, they want their development methodologies back.

Re: How Python virtual environments work

#257

Post by bombolo »

9dev wrote: post #256
bombolo wrote: post #238

Earlier quoted context omitted.

why? Also, you don't have to use them.

Which leaves you with what, not installing packages or sharing packages between everything on my system and all apps I work on? The 80ies just called, they want their development methodologies back.

Is this a response?

I asked what's wrong with a venv and I got a rant…

Re: How Python virtual environments work

#258

Post by bombolo »

MrJohz wrote: post #244
bombolo wrote: post #241

Earlier quoted context omitted.

> they are automatically fixed unless you choose to update them That's a good way to never get vulnerabilities fixed. It hardly seems like "the right thing" to me.

I mean, a project needs regular care and maintenance, however you organise it. If you're never scheduling time to maintain your dependencies, you're going to be in trouble either way. But at least if you lock your dependencies, you know what will actually get installed, and you can find the buggy or insecure versions. We found a bug on a Python project I worked on recently that only seemed to happen on certain machin…

You should really start using linux distributions. These problems are all solved and have been solved for a long time.

Re: How Python virtual environments work

#259

Post by Wowfunhappy »

Doxin wrote: post #248
riffraff wrote: post #228

Earlier quoted context omitted.

Why does that break venv? I thought it'd be linking to things outside of itself but shouldn't be aware of where it is. (Sorry, not a python expert)

When creating the venv it hardcodes some paths so the python interpreter knows where to find its modules and the likes. That said, re-creating a venv shouldn't be hard and if it is you're doing something wrong in your development setup.

What am I doing wrong? As far as I can tell, I have to:

1. Copy my code out from the venv folder

2. Delete the venv folder

3. Make a new venv

4. Copy my code back into the new venv folder

5. Re-install dependencies

This doesn't take much longer than 60 seconds, but that's 55 seconds more than I want to spend. How is this a good process? It just makes me avoid using python (at least when I'd need anything outside the standard library).

Is there a simple command that will do this all for me?

Note that I don't typically have a git repository or similar set up because I use python for very simple semi-throw-away scripts. I just want to be able to rename the containing folder and have my script still work.

Re: How Python virtual environments work

#260

Post by cpburns2009 »

Virtual environments are easy to create and manage. Create one with the built-in venv module:

    python3.10 -m venv ./venv  # or your favorite version
    . ./venv/bin/activate
    pip install pip-tools
Manage dependencies using pip-compile from pip-tools. Store direct dependencies in "requirements.in", and "freeze" all dependencies in "requirements.txt" for deployment:

    . ./venv/bin/activate
    pip-compile -U -o ./requirements.txt ./requirements.in
    pip install -r ./requirements.txt
Post reply on HN