Re: Python packaging, dependencies, upstream facilities

[Piotr Ożarowski <piotr@debian.org>]

[Clint Byrum, 2010-09-22]
> On Sep 21, 2010, at 3:26 AM, Piotr Ożarowski wrote:
> > but this way you cannot `import foo` anymore, you'll have to change all
> > import lines (s/foo/foo2/) even if your code is not affected by API change
> 
> Because languages like python do runtime call resolution, they
> cannot, and should not, be treated like compiled languages in this
> respect.
> 
> In python's case, if I do
> 
> import foo
> 
> x = foo.bar()
> 
> And foo has renamed bar to baz, I won't find out until I actually
> run the code that calls the missing class definition. With C++,
> there's a class missing, and at the bare minimum, I'll fail at link
> time, probably during compile.

you're right, we don't want the Ruby mess in Python

[...]
> Robert is, I think, suggesting that packaging could do this as well.
> Right now each python library can exist on the system once. If it
> conflicts, game over.
> 
> But, if you can get the order of the library loading path right,
> then this structure solves Robert's original desire:
> 
> 
> /usr/share/pyshared/foo1
> /usr/share/pyshared/foo2
> /usr/share/pyshared/foo => foo2
> /usr/share/pyshared/consumer-of-foo1/lib-packages/foo => /usr/share/pyshared/foo1
> 
> 
> This would be quite easily doable in debhelper scripts, and it means
> that users can do 'import foo' in their code, but integrators can
> package things appropriately to override the "whatever version"
> with specific versions.

this approach has exactly the same problem as API in (Python) package
name. Lets say App1 requires foo and bar to work, it needs foo >=2
but bar works only with foo1. By adding consumer-of-foo1/lib-packages/
to sys.path bar is now broken.

> Off the top of my head, these are a few non-trivial issues to solve:
> 
> 
> * What about instances where a dependent-library of consumer-of-foo1
> also wants to 'import foo' but needs foo2? Now I have to make sure
> the entire chain works with foo1. How can I do that?

exactly, so we're back to educating upstreams about importance of stable
API

[...] 
> For working on the CLI, pylons simply spawns a shell that sets
> PYTHONPATH/PYTHONHOME. Likewise, one is required to do so when
> running their particular pylons based app as a web application.
> This allows you to run easy_install or anything else, inside that
> CLI, and the libraries are installed local to the application.

did you mean virtualenv?

> Its not necessarily ideal, but it shows the great lengths one must
> go to to have multiple versions of libraries.

there's also python-wxgtk2.X approach, but I don't like it either
-- 
Piotr Ożarowski                         Debian GNU/Linux Developer
www.ozarowski.pl          www.griffith.cc           www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645