dissent

12 ms·

121.
by dissent 13y ago
Yes, I tend to agree here. However if you're building an RPM, and your python packages will be compiled to binary on the way in. It's not unreasonable in some cases to precompile things to avoid repeatedly doing it.
122.
by dissent 13y ago
This happens to be just where some of my issues come from. When building a monolithic python app into an RPM, Virtualenv was somewhere between annoying and pointless. It's this belief that it actually does something other than set path
123.
by dissent 13y ago
> You'd argue, but you'd lose the argument. Done it already, in production. The virtualenv fanboys didn't even notice. It's simple and elegant and works perfectly.
124.
by dissent 13y ago
There's a level between virtualenv and LXC, and that's schroot. Combine it with a CoW filesystem and that will cover everything you mention. Although personally, I find LXC very lightweight. Note that in my article, I did point ou
125.
by dissent 13y ago
Yeah, the lxc package gives you command line tools that are a close analogue to virtualenv. Combine it with a filesystem like btrfs for copy-on-write, and it's FAR quicker too. I'm glad you mentioned JNI. In Java, native is the ex
126.
by dissent 13y ago
Nope, PYTHONPATH just prepends to sys.path. Does exactly what you say it doesn't do. It's virtualenv that can drop the system, thus necessitating a local copy.
127.
by dissent 13y ago
I read the wheel PEP. I got to the part about munging #! shebang lines and stopped reading. Shebang is just totally irrelevant outside of interactive command line convenience. Just run the python you want to run explicitly! Just like java.
128.
by dissent 13y ago
Provided there's no conflict outside of python, that is. This is also sounds like a deployment scenario, in which case it ought to be non-interactive, in which case you can set sys.path in your entry point. That's the point.
129.
Why I hate virtualenv and pip(pythonrants.wordpress.com)
105 points by dissent 13y ago|113 comments