Live data from Hacker News

You don't really need a virtualenv

frostming.com

81–90 of 148 posts

Re: You don't really need a virtualenv

#81
post #62

Earlier quoted context omitted.

That's just dangerous band-aid. If there is a mismatch between bundled .h and installed system library, you'll get (in better case) linker error, or runtime problems.

Well I was assuming the actual library would be bundled too: not just the headers!

At that point, you should just be installing a binary wheel.

(Nb I’m a maintainer of a python project that’s difficult to build, and the number of issues we get that start: can’t install because foo.h can’t be found is very high, even though there’s other explanations closer to the end of the failed build)

Re: You don't really need a virtualenv

#82
post #62

Earlier quoted context omitted.

That's just dangerous band-aid. If there is a mismatch between bundled .h and installed system library, you'll get (in better case) linker error, or runtime problems.

Well I was assuming the actual library would be bundled too: not just the headers!

That's just the precompiled whl files

Re: You don't really need a virtualenv

#83
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…

Python should just do what JavaScript does and install all dependencies to a project-local folder.

Almost nothing should do what JavaScript does, not even JavaScript. Of all the interpreted languages I’ve used, JS has the single worst ecosystem for running production code. If your experience is primarily with JS, do yourself a favor and try to grok other languages and ecosystems.

Re: You don't really need a virtualenv

#84
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.

That's a fair point actually.

Re: You don't really need a virtualenv

#85

Earlier quoted context omitted.

Not sure if JavaScript has anything that any other language or development tool should copy.

It is a mess... But you can often get a project running an awful lot quicker than in python

True, but if that's the metric we're basing our language choice off of then we should all go back to PHP.

Re: You don't really need a virtualenv

#86

Earlier quoted context omitted.

Well I was assuming the actual library would be bundled too: not just the headers!

At that point, you should just be installing a binary wheel. (Nb I’m a maintainer of a python project that’s difficult to build, and the number of issues we get that start: can’t install because foo.h can’t be found is very high, even though there’s other explanations closer to the end of the failed build)

Does that not happen by default when you try to install a package? And if so, why not?

Re: You don't really need a virtualenv

#87

Earlier quoted context omitted.

JavaScript's package management is significantly better than Pythons: - There's one tool to use, and it comes pre-installed - You don't have to deal with virtualenvs or packages from different projects conflicting. - Native code dependencies "just work".

That one tool must be yarnnpmgypbabelwebpack?

Babel and Webpack aren't package management tools. I guess there is now yarn in addition to NPM. But NPM works just fine. And furthermore they interoperate.

Re: You don't really need a virtualenv

#88
post #67

Earlier quoted context omitted.

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.

>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.

Re: You don't really need a virtualenv

#89
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…

Python should just do what JavaScript does and install all dependencies to a project-local folder.

It does: https://www.python.org/dev/peps/pep-0582/

Though, as the sibling comments say, it's debatable whether it should.

Re: You don't really need a virtualenv

#90

Earlier quoted context omitted.

It is a mess... But you can often get a project running an awful lot quicker than in python

True, but if that's the metric we're basing our language choice off of then we should all go back to PHP.

Yeah no kidding. I prefer it as a prototyping language. Unfortunately, I work in networking, and it's become the raison d'etre for our "DevOps". At least we're not using Ansible anymore... :|
Post reply on HN