[Distutils] Draft PEP for JSON based metadata published

[Nick Coghlan]

On Tue, May 28, 2013 at 12:44 AM, Ronald Oussoren
<ronaldoussoren at mac.com> wrote:
>
> On 27 May, 2013, at 13:36, Nick Coghlan <ncoghlan at gmail.com> wrote:
>
>> After preliminary reviews by Donald and Daniel, I have now pushed the
>> first complete draft of the JSON-based metadata 2.0 proposal to
>> python.org
>>
>> PEP 426 (metadata 2.0): http://www.python.org/dev/peps/pep-0426/
>
> Could platform_release be added to the set of environment markers? On OSX platform.release() returns a kernel version number, while platform.version() returns a string that cannot easily be used as a marker.

Heh, I just checked Linux and it's the same - I don't know where the
original list came from, but adding platform_release sounds good to
me.

> It might also be nice to have markers for the marketing name and version of the OS next to the kernel name and release (for example Solaris 8 vs. SunOS 5.8, or darwin 12.3.0 vs. OSX 10.8.3), but that would probably need a PEP of its own to add the functionality to the stdlib before it is used in metadata.
>
> BTW. Why can marker expressions use only a limited subset of operators? In particular <, <=, > and >= are not allowed and would be nice to have to specify packages that need a minimal platform version (parts of PyObjC have a dependency on the OSX release because the wrapped library is available in a subset of releases). Listing all OS releases would be fairly useless, platform.release() is too specific to use with '==' as new patch releases of OSX can introduce new micro versions of the kernel.

Simple string comparison also works pretty well with Python versions,
too. I think it makes sense to allow them.

>> PEP 440 (versioning): http://www.python.org/dev/peps/pep-0440/
>
> The versioning spec mentions that distribution tools may refuse to publish distributions that pin the versions of dependencies. I understand why this is needed, and agree in general, but have a usecase that I don't know how to express without pinning.
>
> In particular, PyObjC consists of a number of distributions (pyobjc-core, pyobjc-framework-Cocoa, ...) and an umbrella package (pyobjc) what depends on the various distributions to make it easier to install all of PyObjC. The umbrella package currently pins the versions of subpackages to ensure that "pip install pyobjc==2.5.1" installs exactly that version of the entire project.  When I'd use the "compatible release" specifier I can no longer easily ensure that users can install an exact version of the entire project, other than by hacking the system: specify a compatible version with an additional level that isn't used by the project (for example ~=2.5.2.0).  What is the correct way to create an umberella project without getting yelled at by distribution tools?

As noted in a previous email, I've added a specific field for this. It
also highlighted some issues with the way version pinning was
documented in general, so it led to some other changes (like renaming
build labels and build references to source labels and source
references).

The latest drafts should be up on python.org shortly (I just pushed
them to both the PEPs repo and bitbucket)

--
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia