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

111–120 of 148 posts

Re: You don't really need a virtualenv

#111

Post by cozzyd »

toyg wrote: post #73
cozzyd wrote: post #13

Earlier quoted context omitted.

well, a lot of "system" utilities are implemented in Python and I'm not aware of many in Ruby (they must exist? I just checked to see what on my system depends on Ruby and it seems like the only things are a screenruler utility, some texlive packages I've never heard of and gnome-code-assistance, whatever that is). Pip installing random crap is a great way to completely break some Linux systems.

Running pip as root is a great way to self-compromise. Would you ever run npm as root...?

Absolutely... I usually do python setup.py bdist_rpm if I want to install some package systemwide. Not sure it's really any safer, but it sure feels safer...

Re: You don't really need a virtualenv

#112

Post by pfranz »

teraku wrote: post #25
pfranz wrote: post #17

Earlier quoted context omitted.

I haven't used Poetry and most of my workplaces have done their own thing with versioning Python packages. So my virtualenv experience has been on my own or with toy projects. I really like writing one-off or sporadically used commandline tools. Loading a virtualenv or navigating to a directory before executing kind of sucks. Generally, I install into my homedir. I haven't read through or tried this out, but it seems…

You can execute the python binary inside the venv's bin/ folder directly. But you still need the full path I guess

You could add that bin/ to your PATH, but you'd also need something else to load the venv before executing it. You could write a generic wrapper that would load the env and call the Python binary and put that in a more generic bin/, but that's the kind of thing this proposal seems to make irrelevant.

Another issue with wrappers is how quickly it executes. It's not a big deal for most executions, but for --help or building up a command pipeline it's really annoying to wait a second or two on each execution. That slow startup time also shows up when you start integrating it into automated processes.

Re: You don't really need a virtualenv

#113

Post by mmcnl »

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.

Documented workflow. Deterministic execution. pyproject.toml is part of the PEP spec, requirements.txt is just a convention. Explicit vs implicit.

Re: You don't really need a virtualenv

#114

Post by mmcnl »

BiteCode_dev wrote: post #42
orf wrote: post #26

Earlier quoted context omitted.

Honestly just use poetry.

Poetry shell doesn't work on windows, and it doesn't have named venv which matters for some users. Also it's very slow, require to be installed and use proprietary fields in pyproject.toml. It's a great tool but there are reasons you might want something else. Alternative like raw pip, pip tools, or dephell all have various pros and cons.

Not a solution, more a workaround, but on Windows I highly recommend developing using WSL, especially for Python. WSL + pyenv + poetry + VS Code with Remote WSL works amazingly well.

Re: You don't really need a virtualenv

#115

Post by 22c »

BiteCode_dev wrote: post #88
22c wrote: post #67

Earlier quoted context omitted.

>Poetry shell doesn't work on windows What do you mean it doesn't work? It works fine on Windows here, unless I am missing something.

I'm being overly critical. Let's say it has problems: - poetry shell didn't start the same shell that you were in: https://github.com/sarugaku/shellingham/issues/42 . Looks like they fixed it 3 days ago though. - It doesn't set the name of the project in the prompt, so you actually don't know you are in the shell. Very annoying if you have many windows.

>doesn't set the name of the project in the prompt

I agree with you there, it's very annoying and I've fallen for it a few times. Having not used Poetry on other platforms yet (still using Pipenv in a few projects), I wasn't even aware that this was a feature.

Re: You don't really need a virtualenv

#116

Post by user5994461 »

danmur wrote: post #12
cutler wrote: post #9

Earlier quoted context omitted.

He also said virtual envs install their own copy of Python. No need for that either. Coming from other languages the whole virtual env thing seems alien especially the way it messes with your shell.

Activating the venv is completely optional. I never do it, but some people seem to like it.

It's not optional. It's required for things to work properly.

A basic example of something that would break if the environment is not activated is binaries, like mypy.

You have a script that calls "mypy"? Gotta be in the virtual environment to invoke it, otherwise the executable might not be found, or worse, it might run another executable.

Re: You don't really need a virtualenv

#117

Post by smitty1e »

raverbashing wrote: post #54
smitty1e wrote: post #27

> things get tricky when it comes to nested venvs Never had such a requirement. Environments, like the interpreter itself, seem a singleton concept. I have used a Makefile that sources different Bash environment variables kept in files in etc/ within the venv to switch between, say, a Flask and a Gunicorn startup.

Yes you're using nested venvs you're really making it harder on yourself. Way way harder on yourself.

I've used a nested git repository, with the child directory in the .gitignore of the parent. I know that there is some thing about installing git checkouts with pip, but that has not been important to me yet.

Re: You don't really need a virtualenv

#118

Post by isignal »

BerislavLopac wrote: post #107
mqus wrote: post #45

Earlier quoted context omitted.

I have the opinion that this is because "Deployment" is not a solved issue (or clearly defined and enforced) for Python. C has shared libraries and static compilation (bundling of dependencies) Java has .jar files which probably contain all your dependencies, go and Rust statically compile to something that has minimal dependencies and python has... no clue. Some packages you have to install via your package manager…

Or to be precise, it is a solved issue -- several times over. After years of meandering, I think it is safe to say that deployment of Python libraries is pretty much resolved in one, general way: we have the wheel/PyPI/pip toolchain, and that's about it. On the other hand, deployment of Python applications is still unresolved, and there is no single standard method to ensure both compatibility with and isolation from…

All of the above are suitable for deployment on your cloud servers but not as distribution mechanisms to end users. End users cannot set up virtual envs and pip install stuff into them (which sometimes needs external tools like make).

The candidates for distribution are things like pyinstaller or pex (still not fully mature) but I don't think they are as easy to use as Java jars or Go binaries.

Re: You don't really need a virtualenv

#119

Post by frostming »

BiteCode_dev wrote: post #95

My first attempt, and I get "AttributeError: module 'toml.decoder' has no attribute 'TomlPreserveCommentDecoder'" So careful, far from stable. I reported it ( https://github.com/frostming/pdm/issues/247 ) because the project is great and I want it to succeed, but I won't put it in prod any time soon. I prefer my package manager to be stable than fancy. It's also why I don't use poetry and so on in training. There is…

> So careful, far from stable.

True, bugs can't be exposed by a few users. People have vastly different environment setup for their Python development. System python, in-venv, pyenv, asdf, homebrew, etc. So I post it here to seek for help testing.

The sematic versioning may be a bit misleading, it is just because there was a big breaking change to support PEP 621, and I marked it as "Alpha" stage.

Re: You don't really need a virtualenv

#120

Post by beojan »

ajford wrote: post #110
smitty1e wrote: post #27

> things get tricky when it comes to nested venvs Never had such a requirement. Environments, like the interpreter itself, seem a singleton concept. I have used a Makefile that sources different Bash environment variables kept in files in etc/ within the venv to switch between, say, a Flask and a Gunicorn startup.

I honestly can't even come up with a valid reason for something like nested venvs. At that point it seems more like someone's doing something wrong than 'things get tricky'.

If you have unlimited disk space, sure. Otherwise, it would be really nice to be able to layer venvs so you don't need to have multiple copies of a package installed.
Post reply on HN