On 11/20/12, Daniel Holth <dholth@gmail.com> wrote:
> On Tue, Nov 20, 2012 at 3:58 PM, Jim J. Jewett <jimjjewett@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)'?

> 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?

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.

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?