On 27 May, 2013, at 13:36, Nick Coghlan <ncoghlan@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?
It's unlikely PyPI will get more than a warning for ``==``, `is` comparisons might be disallowed? Not sure.
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 | ncoghlan@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