[melbourne-pug] Another project idea (oldie but a goodie)

[Maurice Ling]

>>PyPI, to me, lacks that download-and-install tool I've been mentioning.
>>So, I'll be 150% glad to have my tool to fill that gap.
>>    
>>
>
>You'll be needing support from the web interface to achieve this - see Ian's 
>proposal above. The beauty is that once the web interface supports queries, 
>all of the download-related projects benefit (EasyInstall, Centipyde, 
>Uraga, ...)
>  
>

I can see where you are coming from. On the assumption that PyPI is consistent (which is a set of assumptions), download-and-install related projects (all can be seen as implementations of PEP262 one way or another) can query PyPI through the proposed XML-RPC interface, download the stuffs and install the package.

In order for that to happen, from the viewpoint of a 
download-and-install project, the following set of assumptions must be met in order not to reimplement PyPI in a way or another:

1. each entry in PyPI must have a download URL, otherwise it is useless. (entry for biopython 1.21 has no download url, www.python.org/pypi/biopython/1.21). Entry for book 1.0 (www.python.org/pypi/book/1.0) points to non-existing urls.

2. the download url must be a read downloadable file and a website where you can search for downloads. In this aspect, entry for alo-aes 0.3 (www.python.org/pypi/alo-aes/0.3) meets the criteria while IbPy 0.4 (http://www.python.org/pypi/IbPy/0.4) does not. Although if the download url points to a Sourceforge website, it may be vaguely possible to reconstruct the url to the actual downloadable file (as in the case of matplotlib 0.71, www.python.org/pypi/matplotlib/0.71), it is not possible when the file is hosted out of SF (as in the case of MontyLingua 2.1, www.python.org/pypi/MontyLingua/2.1)

3. there must be a way to tell if any dependencies are needed. Currently, entries in PyPI has no such information.

4. if assumption 3 is met, the names of the dependencies must be consistent with that of the actual package name in PyPI. Say if a package (e.g. Scientific Python 2.4.6, www.python.org/pypi/ScientificPython/2.4.6) requires netCDF 3.6.0, then the name netCDF must be in PyPI (which currently it isn't as www.python.org/pypi/netCDF/3.6.0 is non-existent).

Cheers
Maurice

-------------- next part --------------
A non-text attachment was scrubbed...
Name: mauriceling.vcf
Type: text/x-vcard
Size: 334 bytes
Desc: not available
Url : http://mail.python.org/pipermail/melbourne-pug/attachments/20050619/807e2266/mauriceling.vcf