Ian Bicking: the old part of his blog

Re: Packaging python comment 000

I sort of agree.

There are fewer libraries in Python that can even have true security flaws. Those libraries are usually used in such a fashion that they _can_ be installed system-wide. In fact they should be included with the Python distribution.

All those helper libraries should be bundled separately with the application (as is usually done on Windows) and makes deployment easier.

But what about GUI development? For development, the sandbox approach doesn't work. I find wxWidgets is a pain sometimes because I need to tweak a widget to work well with my applications, since they often don't make subclassing easy. As a developer, sandboxing doesn't make sense because I want to be able to add this tweak to all my applications. But I do want to take advantage of new features, so something like working-env makes sense for all my legacy apps. Maybe that's a problem with the library though.

But what about web development? For hosting, the sandbox approach doesn't work so well for deployers (bundling CherryPy.) In this case it's nice to have a real server that can stay stable underneath.

However, I do agree that the majority of libraries don't belong in site-packages at all. Library dependencies should be resolved by the developer, not the deployer.

Comment on Packaging python comment 000
by Kevin Deenanauth

Comments:

But what about GUI development? For development, the sandbox approach doesn't work. I find wxWidgets is a pain sometimes because I need to tweak a widget to work well with my applications, since they often don't make subclassing easy. As a developer, sandboxing doesn't make sense because I want to be able to add this tweak to all my applications.

You mean you edit the wx code directly? In that case you should probably make a mini fork. Monkeypatching is probably a more realistic option, though. It's a messy situation any way you do it -- I think it's cleaner with monkeypatching though. Monkeypatching someone else's (or everyone else's) application is a little more difficult with isolated installations. So I don't know.

But what about web development? For hosting, the sandbox approach doesn't work so well for deployers (bundling CherryPy.) In this case it's nice to have a real server that can stay stable underneath.

I think the opposite is true. The hoster really doesn't care about CherryPy, and generally doesn't want to maintain or update that for you. On both sides of that relationship people just want things to work and not to have to coordinate and communicate. Bundling CherryPy or whatever your web framework is is probably going to work better for everyone.

# Ian Bicking