[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 -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100922073312.gf15...@piotro.eu
