[Catalog-sig] API search by python version (or classifier)

[Tarek Ziadé]

On Wed, Jan 26, 2011 at 10:33 AM, M.-A. Lemburg <mal at egenix.com> wrote:
> Tarek Ziadé wrote:
>> On Wed, Jan 26, 2011 at 3:36 AM, Brian Jones <bkjones at gmail.com> wrote:
>> ...
>>>> http://mail.python.org/pipermail/catalog-sig/2010-September/003301.html
>>>
>>> I'm not positive we're on the same page. You seem to be talking about adding
>>> some specific new data in a specific way to the index, and *then* making it
>>> available. I'm talking about making the *current* data available to programs
>>> the same way it's available via a web interface. It seems your ideas were
>>> shot down because "it's coming", if I read it right. I myself am kind of
>>> confused about that, because my understanding is also that "it's coming" in
>>> the form of a tool that can only be used for Python 3 packages :/
>>
>> No, the tool will be usable by python2 packages as well.
>>
>> I don't want to do that thread again but basically, egg_info are
>> platform-specific, whereas the new metadata version (PEP 345) will
>> have them right. PyPI already supports PEP 345.
>
> Does that mean that the XML-RPC interface .release_data(package_name, version)
> (see http://wiki.python.org/moin/PyPiXmlRpc for details)
> already returns the full set of PEP 345 meta data ?

Yes I did that change last year. If your package is PEP 345, you'll
get those metadata published.

>
> I don't really see any problem with adding those new fields to the
> .search() API, but perhaps I'm missing something.

If you are talking about the new PEP 345 fields, I don't see any
problem either. having them in the search() API needs to be done, I
forgot to do it IIRC

>
> The discussion Martin mentioned was about egg-infos files or
> directories. It doesn't seem to relate to searching for meta
> data, since - as you say - egg-info is meta data for egg files
> that is individual build files, not releases.

The goal was to publish build data yes, but the intent was to create a
dependency graph by browsing them without having to rebuild them
(that's what easy_install or Pip has to do today).  But they were no
intent to tag them with all the information related to the system that
built them. And we already have them when people are uploading binary
releases (but burried in the archives)

And "searching for dependencies" seems like the same need Brian has.

> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source  (#1, Jan 26 2011)
>>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
> ________________________________________________________________________
>
> ::: Try our new mxODBC.Connect Python Database Interface for free ! ::::
>
>
>   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
>    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
>           Registered at Amtsgericht Duesseldorf: HRB 46611
>               http://www.egenix.com/company/contact/
>



-- 
Tarek Ziadé | http://ziade.org