On Thu, Oct 08, 2009 at 06:56:19PM +0200, kiorky wrote: > > > Toshio Kuratomi a écrit : > > > > Also note, the ability to have multiple versions makes things easier for > > system packagers and provides an easy alternative to a virtualenv for > > end-users. > > > > * System packagers: virtualenv does not provide a method suitable for system > > Yes, there is no doubt virtualenv is useless for system packagers but: > > * System and applications deployment have not to be tied. > It s up to the user to install things system wide or to use locally isolation > technics. Virtualenv is one of those. > As a conclusion, there are not very much problem for system packagers as if > their users have specific needs, they will do something Outside the system. > If not, they use their global python with packages installed in that global one. > This misses the point. If there's two pieces of software to be deployed via system packages and they use two different versions of a module, it's currently not very easy to do this. I do it with setuptools curently even with all its warts. Having a way to do this from within the stdlib that tied directly into the import mechanism would make for a much cleaner situation. In other words, the suggestion that there is no need for a method to install multiple versions of a module because virtualenv is a better solution is bogus. virtualenv is a better solution for creating isolated environments. It is not a solution for all of the cases that being able to install multiple versions of a library would be. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: <http://mail.python.org/pipermail/python-dev/attachments/20091008/5380a169/attachment-0001.pgp>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4