eggs: Python version independence
Most (90%+) of the libraries I work with don't depend on a Python version. But unfortunately when using easy_install/eggs they always have an explicit version, and multiple installations are necessary otherwise. Generally speaking, all pure-Python packages are version independent. At least on the source level. I suppose .pyc files aren't always (though they haven't changed for a long time, have they?) -- would it be reasonable to have version-independent packages? -- Ian Bicking / ianb@colorstudy.com / http://blog.ianbicking.org
On Jul 3, 2005, at 3:07 PM, Ian Bicking wrote:
Most (90%+) of the libraries I work with don't depend on a Python version. But unfortunately when using easy_install/eggs they always have an explicit version, and multiple installations are necessary otherwise.
You shouldn't have a site-packages that multiple Python interpreters are stomping on.. so I don't see how you can avoid this anyway.
Generally speaking, all pure-Python packages are version independent. At least on the source level. I suppose .pyc files aren't always (though they haven't changed for a long time, have they?) -- would it be reasonable to have version-independent packages?
Python 2.4 can use Python 2.3 bytecode, but not vice versa. -bob
Sort of on this topic, handy hint...to maintain a couple of python versions i did this with a bash sript (/usr/local/bin/pypan.sh) called 'pypan' funnily given all the naming issues of late. This just keeps my python instance in sync with each other for when i need to migrate to 2.4 ---8<----pypan.sh-------8<-----8<----------8<-----8<----------8<-----8<----------8<-----8<----------8<----- echo "==================================================" echo "PyPAN - Python Site Packages Installer running...." echo "==================================================" echo "python23 - installing using: /usr/local/Python2.3.4/bin/easy_install.py" python23 /usr/local/Python2.3.4/bin/easy_install.py $1 echo "\n\n" echo "python24 - installing using: /usr/local/bin/easy_install.py" python24 /usr/local/bin/easy_install.py $1 ---8<----pypan.sh-------8<-----8<----------8<-----8<----------8<-----8<----------8<-----8<----------8<----- Ill probably extend this to also use wget and keep a repository of all source packages, but recall seing this functionality in easy_install itself - and since it has better dig options etc best use it i think, long term i would like to use the (-m) option by default to always maintain mutliple versions of a package, but in my first attempt this require() method described failed to import the package that i had installed multiple versions of. Ideally python itself could be extended with the functionality easy_install provides, particularly to resolve latest version when not specified, and to alllow version specification at run time.
At 10:12 AM 7/4/2005 +0100, Clayton Brown wrote:
Ill probably extend this to also use wget and keep a repository of all source packages, but recall seing this functionality in easy_install itself - and since it has better dig options etc best use it i think,
Right now the closest thing is to use the -b option, and the downloaded file will be left in the build directory. But that won't help your script find and reuse the download, I'm afraid.
long term i would like to use the (-m) option by default to always maintain mutliple versions of a package, but in my first attempt this require() method described failed to import the package that i had installed multiple versions of.
What happened instead?
Ideally python itself could be extended with the functionality easy_install provides, particularly to resolve latest version when not specified, and to alllow version specification at run time.
It does allow version specification at runtime; in fact there are already hooks that can be used to make require() automatically run easy_install, and these hooks are in fact already used to install packages' declared dependencies. However, these hooks have to be explicitly activated; simply building this capability into Python's default behavior would be an extreme security risk.
On Jul 4, 2005, at 12:45 PM, Phillip J. Eby wrote:
It does allow version specification at runtime; in fact there are already hooks that can be used to make require() automatically run easy_install, and these hooks are in fact already used to install packages' declared dependencies.
However, these hooks have to be explicitly activated; simply building this capability into Python's default behavior would be an extreme security risk.
What's the best way to turn that on? I haven't seen it referenced in the doc anywhere. I have a case where that would be useful. Ryan Tomayko rtomayko@gmail.com http://naeblis.cx/rtomayko/
At 01:47 PM 7/4/2005 -0400, Ryan Tomayko wrote:
On Jul 4, 2005, at 12:45 PM, Phillip J. Eby wrote:
It does allow version specification at runtime; in fact there are already hooks that can be used to make require() automatically run easy_install, and these hooks are in fact already used to install packages' declared dependencies.
However, these hooks have to be explicitly activated; simply building this capability into Python's default behavior would be an extreme security risk.
What's the best way to turn that on? I haven't seen it referenced in the doc anywhere. I have a case where that would be useful.
Create an instance of AvailableDistributions or a subclass thereof, either overriding the 'obtain()' method, or passing in an 'installer' argument to resolve(). EasyInstall does this in its 'process_distribution()' method, for example. This API is going to change in 0.6 though, when I refactor to match the new spec. In the new spec, 'resolve()' will be an operation on a WorkingSet, which will be allowed to search various sources (e.g. collections of distributions) for possible resolutions. This will make more sense, IMO, than asking a collection to resolve a requirement in terms of a working set. Indeed, the awkwardness of that very mechanism was one of the things that made me realize the architecture needed refactoring.
participants (5)
-
Bob Ippolito
-
Clayton Brown
-
Ian Bicking
-
Phillip J. Eby
-
Ryan Tomayko