4 ms·
You should always use virtual envs. They're a single directory, how are they an abyss? Pip now complains if you try to install a package system wide.
by turtlebits 1y ago
You should always use virtual envs. They're a single directory, how are they an abyss? Pip now complains if you try to install a package system wide.
- unethical_ban 1y agoFor shadow IT, anything that requires "installation" vs. being in the base system or being added as a file to a project is an inconvenience. It's why I like using Bottle for small Python frontends: download the file and import. (I'm ranting based on personal experiences with IT in the past. Yes in general virtualenv is the baseline)
- ActorNightly 1y agoCompile python to executable is always an option.
- shakna 1y agoIf you're dealing with a managed system, chances are, compilers are banned. You'll have to be unsafe and work outside the constrained environment - potentially violating policies, contracts, regulations and laws.
- nomel 1y ago> You should always use virtual envs. If you're not using dependencies, and are writing 3.x code, there's very little justification.
- dapperdrake 1y agoNot using dependencies is rather niche. Most people come to Python because they want to use pre-existing libraries.
- frollogaston 1y agoI don't have to deal with this in JS or I think in other stuff like Golang. I give someone a package.json with versions of everything. npm install always sets deps up locally, but doesn't need to copy the entire NodeJS runtime.
- deathanatos 1y ago… node_modules is your venv. If we use uv from TFA, like the commands are nearly 1:1: npm install <=> uv sync npm install foo <=> uv add foo > It doesn't have to also store a local copy of NodeJS … which Node devs do have a thing for, too, called nvm, written in bash.
- frollogaston 1y agoThe difference is it's default, it always works the same everywhere, it actually writes down the deps, and I don't have to manually switch between them (or set up fancy bashrc triggers) like venvs.
- deathanatos 1y ago> it's default This point is true; the ecosystem simply can't change overnight. uv is getting there, I hope. > it always works the same everywhere `uv` works the same, everywhere? > it actually writes down the deps `uv add` does that, too. > I don't have to manually switch between them (or set up fancy bashrc triggers) like venvs. You don't have to do that with `uv`, either?
- deleted 1y ago[deleted]
- frollogaston 1y agoHope they make uv default then. It's nice, but I have to separately create a project with it, and regular python commands don't work with it, both of which go back to it not being default. But even that won't fix all the old projects.