Python and IDEs

[Chris Angelico]

On Fri, Aug 1, 2014 at 11:10 PM, Steven D'Aprano
<steve+comp.lang.python at pearwood.info> wrote:
> Marko Rauhamaa wrote:
>
>> I'm guessing he's referring to the modern fad of application sandboxing.
>> Each application is installed with everything it needs on top of the
>> basic OS.
>>
>> If you have ten Python apps, you'll have ten Python installations.
>
> A horrible thought. Hard drives are cheap, but not that cheap that one can
> trivially afford to turn every 1K Python script into a 25,000K install
> (based on the size of the Windows binary-only installer). On my system, the
> obvious application directories (I may have missed some) total 460MB:
>
> [steve at ando ~]$ du -hc /bin/ /sbin/ /usr/bin/ /usr/local/bin/
> 7.9M    /bin/
> 38M     /sbin/
> 76K     /usr/bin/mergetools
> 380M    /usr/bin/
> 35M     /usr/local/bin/
> 460M    total
>
> If those apps were an average of 10,000 times larger, that makes 4.6TB,
> significantly larger than an entry level 1TB hard drive. It also makes
> rescue DVDs and boot USB sticks impractical, to say nothing of the expense
> of downloading upgrades. I can download (say) an entire Linux Mint system
> in an hour or three, which is significantly better than the two years it
> would take to download if everything was 10,000 times bigger.

There is a solution. If all those binaries are marked as read-only,
you could have a file system that stores things based on their hashes,
effectively hardlinking (automatically) all the duplicates. Of course,
that only works if they really are duplicates. If one ships Python
2.7.3 and another ships 2.7.4, there'll be a lot of almost-duplicated
files that technically identical.

> But even more problematic... if there's a security vulnerability in Python,
> would you rather wait for the vulnerability to patched once in a central
> Python binary, or individually in each and every single Python script that
> comes with a bundled Python binary?

This is exactly the problem that sandboxing "fixes", though. As soon
as you upgrade the central Python binary, you risk breaking that
application that depended on the exact version that it shipped with.

Encouraging laziness and sloppy versioning, IMO.

>> Also
>> the applications have no way to communicate outside their respective
>> sandboxes. They can't access each others' files, for example.
>
> If two applications can both write to the file system, they can communicate.
> If they have sufficient file system privileges, they can even reach into
> each other's bundle and modify anything they want.

If you chroot to the sandbox, they shouldn't be able to. (Not to say
there's no such thing as chroot leakage, of course, but they
shouldn't.)

>> Personally, I tend to stick to this package management strategy: install
>> whatever is available with yum and write the rest yourself.
>
> +0.8 on that. Sometimes I install software outside of the package management
> system, but I always feel a tad dirty when I do so :-)

I don't. There's plenty that I've done that way - but only ever
applications, or libraries that completely don't exist in the repos.
I've never installed a newer version of a library than I can get from
repo.

ChrisA