Re: [Distutils] [Catalog-sig] Prototype setuptools-specific PyPI index.
At 04:37 PM 7/24/2007 -0400, Noah Gift wrote:
The basic algorithm is that a local index of PyPi could be kept in one file. If an incorrect search was made, the first action to occur would be to check if the local file was the same as the file on the server. If not, it would sync the changes with svn. Then easy_install would try to do lookups against the local file to find a match.
Note that there are a lot of ways you can implement something like this without even involving me on the client or Martin on the server. For example, setuptools.package_index uses urllib2 for all its URL access, so installing an "opener" that does caching before invoking easy_install is possible. You can also subclass the easy_install command class and the PackageIndex class, or tell the easy_install command class to use a different PackageIndex implementation. In the long run, I'd like to add some entry points to allow people to extend the search mechanism in such ways, but for now you can certainly hack subclasses easily enough and make your own alternative commands, as Jim has done for integrating zc.buildout with setuptools.
On 7/24/07, Phillip J. Eby <pje@telecommunity.com> wrote:
At 04:37 PM 7/24/2007 -0400, Noah Gift wrote:
The basic algorithm is that a local index of PyPi could be kept in one file. If an incorrect search was made, the first action to occur would be to check if the local file was the same as the file on the server. If not, it would sync the changes with svn. Then easy_install would try to do lookups against the local file to find a match.
Note that there are a lot of ways you can implement something like this without even involving me on the client or Martin on the server. For example, setuptools.package_index uses urllib2 for all its URL access, so installing an "opener" that does caching before invoking easy_install is possible. You can also subclass the easy_install command class and the PackageIndex class, or tell the easy_install command class to use a different PackageIndex implementation.
In the long run, I'd like to add some entry points to allow people to extend the search mechanism in such ways, but for now you can certainly hack subclasses easily enough and make your own alternative commands, as Jim has done for integrating zc.buildout with setuptools.
Great suggestion! I really like that idea. Does this mean it is also easy to point to another local repository that is available via NFS? I guess a local http mirror would work just as well, if you told the opener about it. This seems like a good way to instruct a sysadmin on how to setup a local customized infrastructure!
participants (2)
-
Noah Gift -
Phillip J. Eby