[Catalog-sig] Another project idea (oldie but a goodie)

[Maurice Ling]

Richard Jones wrote:

>[this is possibly heading off-topic for this list. I suggest follow-up 
>questions be posted to the catalog-sig]
>
>On Sun, 19 Jun 2005 12:13 pm, Maurice Ling wrote:
>  
>
>>>>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.
>>    
>>
>
>Correct.
>
>
>  
>
>>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.
>>    
>>
>
>Correct (well, useless to *you* but not necessarily useless overall ;).
>
>On the PyPI TODO is adding any uploaded files to the download_url list 
>automatically, as currently these are only listed separately.
>
>
>  
>
I do agree that it is useful for everyone, at least to know that there 
is such a module in the world, if anything else. That is why, I 
explicitly state that "from a viewpoint of a download-and-install 
project". From that viewpoint, the question to ask when looking at a 
download url is "where is the file to download?"

>>2. the download url must be a read downloadable file and a website where
>>you can search for downloads.
>>    
>>
>
>I presume the "and" in that sentence was intended to be an "or"?
>  
>
There are 2 errors in this sentence. It should read "the download url 
must be a *real* downloadable file and *not* a website where you can 
search for downloads."

>For answers to this and your subsequent points (3 and 4 on dependencies), I 
>draw your attention again to the relevant PEPs that designed distutils and 
>PyPI. The latest implemented meta-data PEP is:
>
>  http://www.python.org/peps/pep-0314.html
>
>Since this work was only implemented in March this year our biggest problem is 
>that of package maintainers moving over to the more strict definitions of 
>download_url (ie. not some arbitrary URL, but something that must point 
>directly at a file for the release -- this is not enforced, but probably 
>should be) and actually supplying dependency information (requires, provides, 
>obsoletes).
>  
>
This will be great if it is implemented as stated. The toughest part of 
it will be to ensure that the dependencies of a module matches another 
module in PyPI.

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/catalog-sig/attachments/20050620/fdd8d42d/mauriceling.vcf