[Catalog-sig] metadata

[Dan Milgram]

> OSD does alot of things well,  but i have some questions/concerns about it
> and i'm also curious about active state's use.
>
Let me preface by saying that the PPD format is based on OSD but isn't a
100% faithful rendition, and because it is an XML format it is
naturally subject to change.

> - is activestate the only company currently using OSD?
>
Hmm.. Not sure

> - the use of version number seems very restrictive. there is an interesting
> discussion of version numbers in the DistUtils Version.py file. i'm not sure
> that enforcing a triple integer tuple of version numbers is realistic.
>
I agree. And the version.py file has a good approach for comparing
versions - I think a lot of packages out there already adhere to version
strings as in the StrictVersion class. It seems reasonable to make this
the basis for allowable versions, and version comparison. The PPD format
for version strings is too restrictive in its current incarnation.


> - the lack of depedency classification. packages might have different levels
> of depedency ie SUGGEST/REQUIRES for example pygame.
>
In practice I think this distinction will be made by a very minor
fraction of packages out there. In any event this is easily solved by
adding a "LEVEL" attribute that defaults to REQUIRES if not there.

> - the explicit hardcoding of mirrors for codebase
>
This seems reasonable to me in this context

> - some of the values are a bit irrelevant to a python implementation like vm,
> and memsize.
>
Not in use...

> most of my concerns regarding OSD could easily be solved by altering the
> format, i'm just curious how AS handles these things.
>
> - in what way does PPD differ from OSD? is it just a trimming down of the more
> esoteric features of OSD (mem, virtual machine,etc)?
>
Pretty much. There's an additional PYTHONCORE element to specify the
language major minor version in order to handle pakcages with C extensions

> - the use of depedency specification refers the client to another osd file,
> without giving any indication of whats this represents? ie say i want to
> install narval which requires pyxml v0.6.  i have pyxml0.6 installed i
> shouldn't have to grab another file without reason. the only alternative in
> OSD is sometype of file naming convention which requires the client manually
> parsing the url...
>
> of course this brings up an interesting question that i'm unsure how to deal
> with it. it applies more to the client and the server. namely how to deal
> with conflicting depedency versioning requirements. say in the case above the
> client has a newer version of a package than the requirements although the
> narval package might require the older version. how does pyppm deal with this
> on the client side?
>
It doesn't :( pyppm is somewhat immature and doesn't deal with
dependencies - this will be addressed by the
python 2.2 release. ppm - the perl variant - does handle dependencies.
Both versions maintain a cache or registry of sorts, so if a package has a
dependency the cache is checked and the dependent package only need be
downloaded if it isn't there. Dependent packages are specified with
explicit an explicit version number as an attribute. This isn't as
flexible as I'd like it to be. I don't know that there's a particularly
good way to handle packages which require older versions but I think RPM
and Deb packages are probably a better model to work off of eventually.
That said, I think we want to think about this in an evolutionary way -
there's only so much that can be tackled in the first go-around.

Regards,
Dan
-- 
Dan Milgram/ActiveState Developer
New! ASPN - ActiveState Programmer Network
Essential programming tools and information
http://www.ActiveState.com/ASPN