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

You don't really need a virtualenv

frostming.com

Post reply on HN
Print view View original

31–40 of 148 posts

Re: You don't really need a virtualenv

#31

Post by dvfjsdhgfv »

michaericalribo wrote: post #2

> One day a minor release of Python is out It is decidedly not true that I want to update my venv for every minor version bump! I deploy to a cloud service w/ a specific version; my package manager is slow to update; I develop collaboratively using a shared container w/ a fixed version. Updating shared resources with every new release is not always realistic, and that makes it so that I do need (or at least want ) to…

> It is decidedly not true that I want to update my venv for every minor version bump!

I see your point, but testing against every minor version is a great way to spot potential problems (that you'll need to deal with anyway).

Re: You don't really need a virtualenv

#32

Post by amrox »

darkteflon wrote: post #4

This was a good article and looks like an interesting project. Regardless of whether or not you choose to _deploy_ with Docker, _developing_ in Docker containers using the VS Code Remote extensions really solved all of Python's (and Javascript's) annoying packaging problems for me, with the bonus that you also get to specify any additional (non-Python) dependencies right there in the repo Dockerfile and have the deve…

I wish the tooling around devcontainer.json was available separately from VS Code. Most of my company are die-hand vim users. We’ve rolled our own “devcontainer” analog but it’s not nearly as seemless.

Re: You don't really need a virtualenv

#33

Post by guitarbill »

sethammons wrote: post #29
orf wrote: post #26

Earlier quoted context omitted.

Honestly just use poetry.

This comment would be vastly more valuable (to me at least) if you said why. The parent’s workflow mirrors my own and doesn’t feel onerous. Being completely unfamiliar, their site says: > Poetry either uses your configured virtualenvs or creates its own to always be isolated from your system. So it is just a pretty wrapper? I’m missing the value add.

the venv management is a small aspect. pyproject.toml is nicer and saner than setup.py/requirements. easy example: dev dependencies in poetry. poetry's dependency resolver is great. can upload packages with poetry, twine not required (good for CI). works in fish shell, which virtualenvwrapper doesn't. lock files for deploying exactly the same dependency versions.

those are the ones off the top of my head. use poetry, it's great.

Re: You don't really need a virtualenv

#34

Post by imtringued »

rk06 wrote: post #24
cutler wrote: post #6

As a Ruby and Python developer I often wonder why Ruby doesn't need a virtual env. What did Ruby get right that Python didn't?

Not sure about ruby, but most of the languages I know about, C#, javascript, php, etc don't need virtualenv because they install packages in a project locally (and globally if required). so envs of one project do not clash with another. while python install packages globally and only globally . so a virtualenv is needed to isolate different projects from one another

Last time I used python I just did

pip install -r requirements.txt -t libs

and added the folder to PYTHONPATH. I never bothered with virtualenv.

Re: You don't really need a virtualenv

#35

Post by dzonga »

props to the author of this tool. based on what I read from the blog, it's already a step above poetry, which a lot of people rave about recently, but still not good enough not to not use pip. question is, are we going to be nuking the __module__ folder like we nuke node_modules every now and then ? other than I will become an early adopter of the tools. currently using miniconda for my virtualenvs

Re: You don't really need a virtualenv

#36

Post by budafish »

darkteflon wrote: post #4

This was a good article and looks like an interesting project. Regardless of whether or not you choose to _deploy_ with Docker, _developing_ in Docker containers using the VS Code Remote extensions really solved all of Python's (and Javascript's) annoying packaging problems for me, with the bonus that you also get to specify any additional (non-Python) dependencies right there in the repo Dockerfile and have the deve…

Ive never quite managed to get the hang of setting up a dev container. I'ts a bit too tricky for me.

I have resorted to using a throwaway dev container which mimics the local storage of packages. Hopefully someone find the below bash function useful.

The only issue I have using this method is that I cant use VSCode to Debug, which I am hoping to find a nice solution for, but nothing yet.

  function python() {
     docker run \
         -it --rm \
         --name python_$(pwd | sed 's#/home/##g' | sed 's#/#.#g')_$(date +"%H%M%S") \
         -u $(id -u):$(id -g) \
         -v "$(pwd)":"$(pwd)" \
         -w "$(pwd)" \
         -e PROJECT_ROOT="$(pwd)" \
         -e PATH="$(pwd)/vendor/bin/:${PATH}" \
         -e PYTHONUSERBASE="$(pwd)"/vendor \
         -e PYTHONDONTWRITEBYTECODE=1 \
         -e PIP_NO_CACHE_DIR=1 \
         --net=host \
         -h py-docker \
         python:3-slim \
         /bin/bash -c '/bin/bash --rcfile

Re: You don't really need a virtualenv

#37

Post by orf »

sethammons wrote: post #29
orf wrote: post #26

Earlier quoted context omitted.

Honestly just use poetry.

This comment would be vastly more valuable (to me at least) if you said why. The parent’s workflow mirrors my own and doesn’t feel onerous. Being completely unfamiliar, their site says: > Poetry either uses your configured virtualenvs or creates its own to always be isolated from your system. So it is just a pretty wrapper? I’m missing the value add.

Sometimes you don’t realise how onerous things are until you find a better way. Poetry is that way.

Handles dev dependencies, scripts, virtualenv management, upgrading single dependencies, has a lockfile, is super fast, is built on pyproject.toml, etc etc.

Honestly, just use Poetry. At the very least it’s better than ad-hoc personal scripts built around manually managed virtualenvs.

Re: You don't really need a virtualenv

#38

Post by erfgh »

rk06 wrote: post #24
cutler wrote: post #6

As a Ruby and Python developer I often wonder why Ruby doesn't need a virtual env. What did Ruby get right that Python didn't?

Not sure about ruby, but most of the languages I know about, C#, javascript, php, etc don't need virtualenv because they install packages in a project locally (and globally if required). so envs of one project do not clash with another. while python install packages globally and only globally . so a virtualenv is needed to isolate different projects from one another

What do you mean "python install[s] globally and only globally"? That's not true. You can instruct pip to install to any place you want.

Re: You don't really need a virtualenv

#39

Post by williamdclt »

dzonga wrote: post #35

props to the author of this tool. based on what I read from the blog, it's already a step above poetry, which a lot of people rave about recently, but still not good enough not to not use pip. question is, are we going to be nuking the __module__ folder like we nuke node_modules every now and then ? other than I will become an early adopter of the tools. currently using miniconda for my virtualenvs

> are we going to be nuking the __module__ folder like we nuke node_modules every now and then ?

Two thoughts:

1. Part of the good aspect of the node_modules is its nukeability. It's a good thing that we can blindly nuke and `npm i`

2. With node and react (I have 5 node projects and 2 react projects that I work on regularly), I really rarely have such error that I need to nuke the node modules. `npm i` to update dependencies and restarting the server because it got stuck in a weird state is usually the solution. I nuke a node_modules maybe every 3 months, probably less. On react-native, yeah it's still very much a thing though

Re: You don't really need a virtualenv

#40

Post by BiteCode_dev »

dissent wrote: post #30

Thanks for writing this. I've always felt that virtualenv was bit of a placebo. I still use it from time to time though because others expect it. In fact I have used it this week on MacOS, and was annoyed to find that I can't install ipdb to my user packages and still see it in a virtualenv. Seems it's either global or local. (I think the --system-site-packages defaulting to off has it backwards, but it is probably r…

-m is the replacement for console scripts. Well behaved cli should define a _ _ main _ _. Py

Pytest, pylint, black, pip, poetry, mypy all have one.

Jupyter one is buggy.

Post reply on HN