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

191–200 of 293 posts

Re: How Python virtual environments work

#191

Post by danielvaughn »

hot_gril wrote: post #182
danielvaughn wrote: post #180

Earlier quoted context omitted.

I remember trying to use cocoapods back in 2015/2016, right around the time that Swift was technically available but not ready for production. I literally gave up trying to import packages, it was a shitshow.

I first used Swift at the same time. Cocoapods actually worked, but only after fighting it all day. Swift was recommended over ObjC, but it was broken. The compiler itself would segfault if I used the wrong map syntax. If the compiler worked, it took about 20X as long as an ObjC build. Core Data managed to produce non-optional objects that were nil in some cases. Swift got fixed over time (which is why every basic SO…

I try not to hate on projects publicly, because I know a lot of devs smarter than me pour their sweat and tears into these things. But imagine releasing a new language in 2014 and fucking up strings.

Re: How Python virtual environments work

#192

Post by buildbot »

tryauuum wrote: post #169
buildbot wrote: post #166

Earlier quoted context omitted.

Good? I don't want my package manager messing with my cuda toolkit setup!

? what if you need two different versions of cuda toolkit on same machine?

I may be wrong, but I don’t think you would want that - it should match with your driver version. Weird stuff happens with minor version mismatches

Re: How Python virtual environments work

#193

Post by nodemaker »

TheRealPomax wrote: post #190
haskellandchill wrote: post #187

Earlier quoted context omitted.

> Except when you try to move it, or copy it to a different location. The article says it is explicitly not designed for that: "One point I would like to make is how virtual environments are designed to be disposable and not relocatable."

Good job, you spotted the exact problem: that's what they were originally for, and that makes no sense in 2023 (or 2020, or the day venv functionality was added into main line Python) where literally everything a venv does is trivially achieved in a new location if it didn't hardcode everything relating to paths . There is literally nothing about a venv that somehow magically makes it impossible to still work after r…

Jeez just clone a venv with venv cloning tools

Re: How Python virtual environments work

#194

Post by epgui »

wheelerof4te wrote: post #119
pbronez wrote: post #80

Earlier quoted context omitted.

Until you want to use anything with a c extension..

Why would you want to use Python with a C extension? If you need performance, just use native code.

> Why would you want to use Python with a C extension?

Because if you need performance, you need to use native code.

Re: How Python virtual environments work

#196

Post by fbdab103 »

TheRealPomax wrote: post #146
_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…

Except when you try to move it, or copy it to a different location. This _almost_ made sense back when it was its own script, but it hasn't made sense for years, and the obstinacy to just sit down and fix this has been bafflingly remarkable. ("why not make everyone install their own venv and run pip install?" because, and here's the part that's going to blow your mind: because they shouldn't have to . The vast majori…

I have drunk the Python kool-aid for too long, but you are absolutely right that this should be corrected.

Re: How Python virtual environments work

#197

Post by Groxx »

lmm wrote: post #174
Groxx wrote: post #96

Earlier quoted context omitted.

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.

venvs are the recommended workaround for the fact that python packaging and distribution is a mess of global state. Lanugages with working packaging and distribution don't generally bother with anything venv-like.

Sure, but that's like 99% pip. Venvs are patching it (quite effectively), not causing it.

Re: How Python virtual environments work

#198

Post by epgui »

mixmastamyk wrote: post #184
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…

Basically the point is to avoid the system python, which is not hard. One needs some sys-ad skills to understand what is going on however; unfortunately sounds like they are short supply. I don't do anything you mention, so there must be a simpler way.

It may not be hard to avoid system python, but that doesn't mean it's not also easy to mess everything up in 99 different barely-reproducible ways. I'm perfectly comfortable setting up python for projects I work on (with maybe 2-3 different methods), but that doesn't mean it's user-friendly or beginner-friendly. It doesn't mean the abstractions aren't taxing. I really agree with a lot of the criticism here.

Re: How Python virtual environments work

#199

Post by PaulHoule »

zelphirkalt wrote: post #188
PaulHoule wrote: post #51

Earlier quoted context omitted.

Python has always struggled with distribution maintainers that just don’t get it. Python barely survived becoming the default scripting language on Red Hat and other Linux distros which was a major obstruction to the Python 3 transition. If the new cohort of pandas and scikit-learn users had not been such a force of nature we”d be talking today about Python the way we do about Perl. Not installing venv is a serious c…

You can easily install python3-venv as a package. Why should it be installed by default, when many users will never use it?

Because people are lazy and the right thing must be easier then the wrong thing. The main project in Python now (going well) is removing the footguns, and

   pip install —-user
Is one of them. If users don’t have venv they will trash their Python installation almost right away and probably join the many people who’ve left Python.

Re: How Python virtual environments work

#200

Post by ospider »

coldtea wrote: post #141
whalesalad wrote: post #104

Earlier quoted context omitted.

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.

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.
Post reply on HN