Chris Withers wrote: > I think you're missing my point: how would the package be named and/or how > would you express in static metadata, that a particular version of the > package is for postgres 8 rather than postgres 7, or 8.4 rather than 8.3?
Just to add my 2 cents: It seems to me that there are two sets of metadata getting confused here. One is the existing set including the Python dependencies. This set is meant to describe what the package does and relies on conceptually. The other is a set of system dependencies that describe in what precise environment a binary egg happens to have been built. The latter are currently expressed only in the file name of the egg or not at all. The set of system dependencies can be taken to be empty for a source egg and includes the target platform and architecture, some of the options Python was built with (what flavour of unicode, which optional libraries compiled in), and a set of third-party system libraries with or without version restrictions. Of the system dependencies, only the platform and architecture are currently accessible (through the egg file name) when downloading an egg, which is one of the reasons why releasing binary eggs for Linux is so unpopular - you might just end up with an unforeseeable mismatch of unicode flavour between your Python and the binary egg. In a dream world, a package index would have an API that allows an installer to query what system dependencies are relevant to binary eggs of a given package and for which combinations of values binary eggs actually exist. The installer could then figure out which of them fits its actual environment best or whether to get the source egg and roll its own binary. -- Thomas _______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
