[Catalog-sig] Another project idea (oldie but a goodie)
mauriceling at acm.org
Mon Jun 20 01:12:04 CEST 2005
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.
>>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:
>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,
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 334 bytes
Desc: not available
Url : http://mail.python.org/pipermail/catalog-sig/attachments/20050620/fdd8d42d/mauriceling.vcf
More information about the Catalog-sig