On 27 May, 2013, at 13:36, Nick Coghlan <ncogh...@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. 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. > 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? Ronald > > With the rationale and commentary, they're over 3000 lines between > them, so I'm not attaching them here. > > The rationale for many of the changes is at the end of each PEP, along > with some comments on features that I have either rejected or > deliberately chosen to defer to the next revision of the metadata (at > the earliest). > > Those with BitBucket accounts may also comment inline on the drafts here: > > PEP 426: > https://bitbucket.org/ncoghlan/misc/src/05d3586464b10d6a04a35409468269d7c89a87ba/pep_drafts/pep-0426.txt?at=default > PEP 440: > https://bitbucket.org/ncoghlan/misc/src/05d3586464b10d6a04a35409468269d7c89a87ba/pep_drafts/pep-0440.txt?at=default > > Cheers, > Nick. > > -- > Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG@python.org > http://mail.python.org/mailman/listinfo/distutils-sig _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
