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

51–60 of 293 posts

Re: How Python virtual environments work

#51

Post by PaulHoule »

lockhouse wrote: post #45
tmpz22 wrote: post #44

Earlier quoted context omitted.

* Local state is changing such as brew updates or new dependencies are added. * External state is changing such as project contributions So its not a one-off unless the project and dev environment is static. The real problem is different tooling doing different amounts of hand holding and automation. Your editor may configure some things automatically, brew may configure some things automatically, and so a set of ins…

Isn’t it considered best practice not to use brew to install Python for exactly this reason? I’ve always seen it recommended to use pyenv or just download directly from Python.org instead.

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 crime on the part of Debian as beginners don’t need any more excuse to trash their system with site-local directories and other wrong answers for how to manage packages in Python.

Re: How Python virtual environments work

#52

Post by PaulHoule »

chao- wrote: post #20
ginko wrote: post #16

Earlier quoted context omitted.

That's just giving up.

Yes it is giving up, but not only. It is giving up and being able to get back to the actual work you want to be doing.

I worked at a place where people tried using Docker to manage Python and wound up with a bunch of twisty little images that were all misconfigured in a different way. (E.g. default charsets that I’m not sure anybody uses.)

Re: How Python virtual environments work

#53

Post by winrid »

tomalaci wrote: post #49

I would highly recommend Poetry for python package management. It basically wraps around pip and venvs offering a lot of convenience features (managing packages, do dist builds, etc.). It also works pretty nicely with Tox. I would recommend using virualenvs.in-project setting so Poetry generates venv in the project folder and not in some temporary user folder.

Thanks. I recently spent a whole afternoon learning how to package a new python project. Was really surprised at the difficulty even with venv, compared to node and java.

Re: How Python virtual environments work

#54

Post by silverwind »

danielvaughn wrote: post #42
dangerlibrary wrote: post #15

Earlier quoted context omitted.

I hate python package management - I really do. But I've never actually had a problem with virtual environments, and I think it's because I just use virtualenv directly (rather than conda or whatever else). I have these aliases in my .bashrc, and I can't remember the last time I had a major issue. alias venv='rm -rf ./venv && virtualenv venv && source ./venv/bin/activate' alias vact='source ./venv/bin/activate' alias…

A few weeks ago I spent about a week debugging my Poetry environment. Turns out, their latest release (which I believe was a patch bump!) brought in some breaking changes. And on top of that, a bunch of stuff was forcing python3.11 under the hood, whereas I was on python3.10. It was a nightmare.

Poetry seems to break compatibility with every release of either itself or Python, double the fun.

Re: How Python virtual environments work

#55

Post by Havoc »

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

Re: How Python virtual environments work

#56

Post by cstrahan »

danielvaughn wrote: post #43
birdstheword5 wrote: post #24

Earlier quoted context omitted.

It sounds mean to say it, but it's 100% true. I moved away from using python wherever I can. I've had colleagues struggle for days to install well used packages like pandas and numpy in conda.

I just began writing Python a few months ago. For years prior, I'd been a JS dev, and while NPM can be frustrating at times, I never encountered so many issues as I have in Python. It's crazy. I'm now curious whether there are languages out there that do have a really nice packaging system.

FWIW, I find Cargo to be one of the biggest reasons I like Rust so much — maybe even more than anything to do with Rust itself or safe code.

I’ll often look for command line tools written in Rust, but not because of Rust fanboyism, but because I know I can just git clone the project and immediately start hacking on a new feature I need or a quick bug fix. In almost every other language I have to jump through one million hoops before I can build and run whatever it is, let alone have a nice developer experience (autocomplete, go to definition, etc).

Re: How Python virtual environments work

#57

Post by cpach »

danielvaughn wrote: post #43
birdstheword5 wrote: post #24

Earlier quoted context omitted.

It sounds mean to say it, but it's 100% true. I moved away from using python wherever I can. I've had colleagues struggle for days to install well used packages like pandas and numpy in conda.

I just began writing Python a few months ago. For years prior, I'd been a JS dev, and while NPM can be frustrating at times, I never encountered so many issues as I have in Python. It's crazy. I'm now curious whether there are languages out there that do have a really nice packaging system.

IMHO, Go’s packaging system is very pleasant to use.

Re: How Python virtual environments work

#58

Post by kgodey »

dangerlibrary wrote: post #15
Max_Limelihood wrote: post #8

Answer: they don’t (Seriously, I’ve gotten so fed up with Python package management that I just use CondaPkg.jl, which uses Julia’s package manager to take care of Python packages. It is just so much cleaner and easier to use than anything in Python.)

I hate python package management - I really do. But I've never actually had a problem with virtual environments, and I think it's because I just use virtualenv directly (rather than conda or whatever else). I have these aliases in my .bashrc, and I can't remember the last time I had a major issue. alias venv='rm -rf ./venv && virtualenv venv && source ./venv/bin/activate' alias vact='source ./venv/bin/activate' alias…

I use virtualenvwrapper[1] and can't remember any problems with virtual environments either. It sets up human readable aliases for you like "mkvirtualenv" to create a virtualenv and "workon" to activate a virtualenv.

[1] https://github.com/python-virtualenvwrapper/virtualenvwrappe...

Re: How Python virtual environments work

#59

Post by cpach »

PaulHoule wrote: post #52
chao- wrote: post #20

Earlier quoted context omitted.

Yes it is giving up, but not only. It is giving up and being able to get back to the actual work you want to be doing.

I worked at a place where people tried using Docker to manage Python and wound up with a bunch of twisty little images that were all misconfigured in a different way. (E.g. default charsets that I’m not sure anybody uses.)

Learning to make sound container images is tricky, but once you got it figured out it is, IMO, a very nice way to distribute software.

Re: How Python virtual environments work

#60

Post by nerdponx »

tomalaci wrote: post #49

I would highly recommend Poetry for python package management. It basically wraps around pip and venvs offering a lot of convenience features (managing packages, do dist builds, etc.). It also works pretty nicely with Tox. I would recommend using virualenvs.in-project setting so Poetry generates venv in the project folder and not in some temporary user folder.

I prefer Hatch over Poetry. I don't have any strong reason for that preference, I've just use both and I feel more comfortable with Hatch. It feels a little more seamlessly integrated with other Python tools, and I appreciate the developers' conservative approach to adding features.
Post reply on HN