[Distutils] distlib and wheel metadata

[Nathaniel Smith]

On Thu, Feb 23, 2017 at 12:44 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On 23 February 2017 at 18:37, Paul Moore <p.f.moore at gmail.com> wrote:
>>
>> On 23 February 2017 at 08:18, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> > I'm not a huge fan of having simple boolean toggles in metadata
>> > definitions
>> > (hence the more elaborate idea of two different kinds of dependency
>> > declaration), but this may be a case where that's a good way to go,
>> > since it
>> > would mean that services and tools that care can check it (with a
>> > recommendation in the spec saying that public index servers SHOULD check
>> > it), while those that don't care would continue to have a single unified
>> > set
>> > of dependency declarations to work with.
>>
>> While boolean metadata may not be ideal in the general case, I think
>> it makes sense here. If you want to make it more acceptable, maybe
>> make it Package-Type, with values "application" or "library".
>
>
> That gets us back into the world of defining what the various package types
> mean, and I really don't want to go there :)
>
> Instead, I'm thinking in terms of a purely capability based field:
> "allow_pinned_dependencies", with the default being "False", but actually
> checking the field also only being a SHOULD for public index servers and a
> MAY for everything else.
>
> That would be enough for downstream tooling to pick up and say "I should
> treat this as a multi-component module rather than as an individual
> standalone component", *without* having to inflict the task of understanding
> the complexities of multi-tier distribution systems onto all component
> publishers :)

I'm still not sure I understand what you're trying to do, but this
feels like you're trying to have it both ways... if you don't want to
define what the different package types mean, and it's purely a
capability-based field, then surely that means that downstream tooling
*can't* make assumptions about what kind of package type it is based
on the field? ISTM that from the point of view of downstream tooling,
"allow_pinned_dependencies" carries literally no information, because
all it means is "this package is on a public server and its
Requires-Dist field has an == in it", which are things we already
know. I can see how this would help your goal of educating uploaders
about good package hygiene, but not how it helps downstream
distributors.

(Here's an example I've just run into that involves a == dependency on
a public package: I have a library that needs to access some C API
calls on Windows, but not on other platforms. The natural way to do
this is to split out the CFFI code into its own package,
_mylib_windows_helper or whatever, that has zero public interface, and
have mylib v1.2.3 require "_mylib_windows_helper==1.2.3; os_name ==
'nt'". That way I can distribute one pure-Python wheel + one binary
wheel and everything just works. But there's no sense in which this is
an "integrated application" or anything, it's just a single library
that usually ships in one .whl but sometimes ships in 2 .whls.)

((In actual fact I'm currently not building the package this way
because setuptools makes it extremely painful to actually maintain
that setup. Really I need the ability to build two wheels out of a
single source package. Since we don't have that, I'm instead using
CFFI's slow and semi-deprecated ABI mode, which lets me call C
functions from a pure Python package. But what I described above is
really the "right" solution, it's just tooling limitations that make
it painful.))

-n

-- 
Nathaniel J. Smith -- https://vorpus.org