On 21 Jun 2013 00:36, "holger krekel" <hol...@merlinux.eu> wrote: > > > I still think the testing part of "the interchange format > between software publication and integration tools" is underspecified. > The dependencies alone will not be sufficient to allow the running > of tests in many cases. Or am i missing something?
If "setup.py test" works for a distribution today, it will still work under PEP 426. Anything more is deliberately deferred (as noted in the PEP). Cheers, Nick. > > best and thanks for your good work, > > holger > > On Thu, Jun 20, 2013 at 23:07 +1000, Nick Coghlan wrote: > > New versions of PEP 426 and PEP 440 are up on python.org: > > > > PEP 426 (metadata 2.0): http://www.python.org/dev/peps/pep-0426/ > > PEP 440 (version spec): http://www.python.org/dev/peps/pep-0440/ > > > > (as before, not including them inline due to sheer length) > > > > The bulk of the changes are in this commit: > > http://hg.python.org/peps/rev/de305af601fa > > (there are a few minor tweaks in subsequent commits to the PEPs repo) > > > > There have been several significant changes to the main metadata spec > > in PEP 426: > > > > * Added a basic "jsonschema" based description of the format > > * The "abbreviated metadata" notion is gone, replaced by "included > > documents". The metadata can now list the names of additional files > > included in the distinfo directory for the long description, the > > license and the change history. The contents are no longer embedded > > directly in the metadata (but will be extracted and made available by > > PyPI, with the markup format being determined from the file extension, > > just as it is by sites like GitHub) > > * The dependency system has been redesigned under the name "Semantic > > dependencies" (as they now allow a distribution to better say *why* a > > dependency is needed, rather than just saying "I need this" with > > almost no capacity to say why). There are now five kinds of > > dependencies (:meta:, :run:, :test:, :build: and :dev:) and they're > > integrated into the extras system so you can easily say you want to > > install some, none or all of them. > > * The "*" notation is added to extras to make it easier to say > > "install all dependencies", along with the "-extra_name" notation to > > exclude the dependencies for specific extras > > * The "-" notation is added to extras to make it easier to install > > *just* a distribution's dependencies, without installing the > > distribution itself. > > * "Install hooks" are now a distinct concept from the > > still-hypothetical "metabuild" system, and place more constraints on > > their expected handling (installation tools are also explicitly > > permitted to refuse to run them, but doing so is required to fail > > noisily rather than silently appearing to succeed) > > > > The most significant change to PEP 440 is to the handling of > > pre-releases: whether or not pre-releases should be accepted by > > default is now determined solely by whether or not there is a stable > > release that *also* satisfies the version specifier. Reference a > > pre-release (or not) now has no effect on whether pre-releases are > > considered viable candidates. Pre-releases are now accepted if: > > * they're already installed > > * there's no other available option > > * the installation tool is told specifically to consider them > > > > Other less significant changes to PEP 426 include: > > > > * Longer introduction giving more context for the nature and purpose > > of the metadata > > * Separated various other things out into appendices > > * Various tweaks to definitions (including the "Release" tweak from > > PEP 440, and switching "source archive" to refer to the original raw > > source, while using "sdist" for the Python specific format with the > > extra metadata) > > * Blanket permission for distribution related online services to > > impose additional restrictions to protect the integrity of the service > > (such as additional length limits beyond those stated in the PEP). > > * Explicitly require UTF-8 encoded JSON for serialisation > > * build_label renamed to source_label > > * version_url renamed to source_url > > * tightened up the validation rules for various fields (including RFC > > references where appropriate). Many of these "new" rules are things > > projects already comply with (because not complying doesn't work > > properly). Including them in the spec is about giving PyPI clear > > guidance to enforce them at point of upload, rather than leaving it to > > installation tools to try to sort out later. > > * a few more additions to the "Rejected Features" appendix (notably, > > my rationale for *not* requiring the install hooks to accept arbitrary > > keyword arguments) > > > > The other PEP 440 changes are also relatively minor: > > > > - what were previously called releases are now "final releases", > > freeing up "release" as a general term for any kind of release > > (developmental release, pre-release, final release, post release). > > - "source references" are now "direct references" and can also refer > > to prebuilt wheel files > > - automated tools (especially index servers) are given a lot of > > freedom to be opinionated about the appropriate uses for direct > > references > > - a few tweaks to the security guidelines for direct references > > - pytz/Olson database version translation is explicitly discussed (add > > a leading 0., convert the trailing letter to an incrementing number) > > - tighter rules for what characters are allowed in a source label > > > > The only major remaining open item is the addition of guidelines in > > Appendix A for converting legacy metadata to metadata 2.0. I consider > > the rest of the spec stable at this point, unless anyone picks up on a > > glaring hole in the latest draft that Daniel, Donald and I missed. > > > > 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