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? 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)'? >> (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"? 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?) Is the payload assumed to be utf8 text? Can it be itself a mime message? 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? '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? '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. 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 appendix gives code for generating and parsing continuation lines that suggests the continuation whitespace is exactly one tab -- is other whitespace OK too? -jJ _______________________________________________ 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
