On Tue, Nov 20, 2012 at 7:18 PM, Jim Jewett <jimjjew...@gmail.com> wrote:
> On 11/20/12, Daniel Holth <dho...@gmail.com> wrote: > > On Tue, Nov 20, 2012 at 3:58 PM, Jim J. Jewett <jimjjew...@gmail.com> > > wrote: > > >> Vinay Sajip reworded the 'Provides-Dist' definition to explicitly say: > > >> > The use of multiple names in this field *must not* be used for > >> > bundling distributions together. It is intended for use when > >> > projects are forked and merged over time ... > > >> (1) Then how *should* the "bundle-of-several-components" case be > >> represented? > > > The useful way to bundle a bunch of things would be to just include them > > all in an executable folder or zipfile with __main__.py. PEP 426 and the > > package database would not get involved. The bundle would be distributed > as > > an application you can download and use, not as an sdist on PyPI. > > When I look at, for example, twisted, there are some fairly fine > distinctions. > > I can imagine some people wanting to handle each little piece > differently, since that is the level at which they would be replaced > by a more efficient implementation. That doesn't mean that someone > using the default should have to manage 47 separate little packages > individually. > > Also note that ZODB is mentioned as a bundling example in the current > (2012-11-14) PEP. What does the PEP recommend that they do? Stop > including transaction? Keep including it but stop 'Provides-Dist'-ing > it? > > The current PEP also specifies that "This field must include the > project identified in the Name field, followed by the version : Name > (Version)." but the examples do not always include version. Why is > the MUST there? > ZODB is a bad example. The word "bundling" will be struck from the PEP entirely. Two sdists should not be combined into one sdist when both packages are still being developed. If A and B are merged into a single PyPI package C, and A and B will no longer be developed, then C may Provides-Dist A and B. http://www.python.org/dev/peps/pep-0426/#requires-dist-multiple-use No MUST on the Requires-Dist version. If no version is there, it should satisfy any version requirement. Is there some way to distinguish between concrete and abstract > provisions? For example, if MyMail (2012.11.10) includes > 'Provides-Dist: email', does that really get parsed as 'Provides-Dist: > email (2012.11.10)'? > No. >> (2) How is 'Provides-Dist' different from 'Obsoletes-Dist'? >> The only difference I can see is that it may be a bit more polite >> to people who do want to install multiple versions of a (possibly >> abstract) package. > The intent of Provides and Obsoletes is different. Obsoletes would not > > satisfy a requirement during dependency resolution. > > > The RPM guide explains a similar system: > > As best I can understand, Obsoletes means "Go ahead and uninstall that > other package." > Saying that *without* providing the same functionality seems like a > sneaky spelling of "Please break whatever relies on that other > package." > > I'm willing to believe that there is a more useful meaning. I'm also > willing to believe that they are logically redundant but express > different intentions. The current wording doesn't tell me which is > true. (Admittedly, that is arguably an upstream bug with other > package systems, but you should still either fix it or explicitly > delegate the definitions.) > > And as long as I'm asking for clarification, can foopkg-3.4 obsolete > foopgk3.2? If not, is it a semantics problem, or just not idiomatic? > If so, does it have a precise meaning, such as "no longer > interoperates with"? > When I used Obsoletes, it meant "I am no longer developing this other package that is identical to this re-named package". The system of requirements/conflicts (as the RPM system) does not appear to be entirely orthogonal. And now that I've looked more carefully ... > > Can a "Key: Value" pair be continued onto another line? The syntax > description under "Metadata Files" does not say so, but later text > suggests that either leading whitespace or a leading tab specifically > (from the example code) will work. (And is description a special > case?) > Description (now in the payload, please) is the only field that is commonly multi-line. Any field could continue onto the next line as far as the parser is concerned. It probably would not make sense. Is the payload assumed to be utf8 text? Can it be itself a mime message? > The entire file needs to be utf-8. The payload is assumed to be utf-8 text in this version. Wouldn't a mime message also be utf-8 text? (we wouldn't know what to do with it) > Are there any restrictions on 'Name'? e.g., Can the name include > spaces? line breaks? Must it be a valid python identifier? A valid > python qualname? > setuptools constrains it to alphanumeric characters. Metadata 1.3 doesn't say. 'Version' says that it must be in the format specified in PEP 386. > Unfortunately, it doesn't say which part of 386. Do you mean that it > must be acceptable to verlib.NormalizedVersion without first having to > call suggest_normalized_version? > It means it is expected to match: http://www.python.org/dev/peps/pep-0386/#the-new-versioning-algorithm expr = r"""^ (?P<version>\d+\.\d+) # minimum 'N.N' (?P<extraversion>(?:\.\d+)*) # any number of extra '.N' segments (?: (?P<prerel>[abc]|rc) # 'a' = alpha, 'b' = beta # 'c' or 'rc' = release candidate (?P<prerelversion>\d+(?:\.\d+)*) )? (?P<postdev>(\.post(?P<post>\d+))?(\.dev(?P<dev>\d+))?)? $""" Please do not enforce this regexp in your Metadata parser. > 'Summary' specifies that it must be one line. Is there a character > limit, or do you just mean "no line breaks"? Do you want to add a > "Should be less than 80 characters" or some such, based on typical > tool presentation? Would it be worth repeating the advice that longer > descriptions should go in the payload, after all headers? (Otherwise, > they have to find 'Description' *and* notice that it is deprecated and > figure out what to do instead.) > > Under 'Description', it isn't entirely clear whether what terminates > the field. "Multiple paragraphs" suggests that there can be multiple > lines, but I'm guessing that -- in practice -- they have to be a > single logical line, with all but the first starting with whitespace. > Non-blank lines that don't start with whitespace are keys. email.parser.Parser() takes care of this in an e-mail-inspired (but not any literal RFC) way. The distutils documentation has guidelines on the short description / summary. > Under 'Classifier', is PEP 301 really the current authority for > classifiers? I would prefer at least a reference to > http://pypi.python.org/pypi?%3Aaction=list_classifiers demonstrating > which classifiers are currently meaningful. > > Under 'Requires-Dist', there is an unclosed parenthesis. > > Does the 'Setup-Requires-Dist' set implicitly include the > 'Requires-Dist' set, or should a package be listed both ways if it is > required at both setup and runtime? > > The Summary of Differences from PEP 345 mentions changes to > Requires-Dist, but I don't know what they were -- even the unclosed > parentheses seemed the same. > The addition of the allowed "extra" variable in the ; condition is the most significant change. > The appendix gives code for generating and parsing continuation lines > that suggests the continuation whitespace is exactly one tab -- is > other whitespace OK too? > Any whitespace would work.
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
