[prev in list] [next in list] [prev in thread] [next in thread] 

List:       python-distutils-sig
Subject:    Re: [Distutils] Comments on PEP 426 and 459
From:       Daniel Holth <dholth () gmail ! com>
Date:       2014-04-09 12:14:15
Message-ID: CAG8k2+7_c_4FMGm1FKgpEXvrXiUXRFBsGgKq6kx6DqbNA5RxvA () mail ! gmail ! com
[Download RAW message or body]

On Wed, Apr 9, 2014 at 6:41 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:
> On 8 April 2014 08:44, Daniel Holth <dholth@gmail.com> wrote:
>> On Mon, Apr 7, 2014 at 11:59 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:
>>>
>>> On 7 Apr 2014 23:15, "Daniel Holth" <dholth@gmail.com> wrote:
>>> Meta distribution is an essential part of encouraging decoupled component
>>> design, without increasing the complexity of consuming an overall "release".
>>
>> Is the entire justification for this feature not "we don't trust you
>> to put == in run_requires", while exposing the same now-frustated
>> users to the same problem once they rename run_ to meta_? Instead of
>> having a separate but nearly identical top-level key, the == in
>> run_requires and not providing any actual modules could cause a
>> meta-distribution, and unwanted == in poorly written upstream
>> dependencies could be handled by a "patch" directive in the install
>> tool (like in buildout).
>
> There's a reason I refer to the new dependency model as "semantic
> dependencies" - the five categories are based on what the dependencies
> *mean*, moreso than when they're relevant. Those meanings then
> translate to whether or not pinning is appropriate on a public index
> server.
>
> With dev vs build vs run/meta vs test, the distinctions are obvious,
> because they're dependencies that are needed for *specific
> activities*:
>
> - run the software (run+meta)
> - run the automated test suite (test+run+meta)
> - build the software (build)
> - work on the software (dev+build+test+run+meta)
>
> With run vs meta, the distinction is a little more subtle, as it
> relates to the *commitments being made to users*, even though they
> both apply to running the software.
>
> The normal case is to use "run" - that means you're operating in a
> pure publisher role, and integration and responding in a timely manner
> to security updates for dependencies is the responsibility of the
> software consumer. This is what you're going to want in almost all
> cases when publishing to a public index server like PyPI.
>
> The "meta" case is different, as that represents a *pre-integrated*
> bundle of software - you're operating in a hybrid publisher/integrator
> role, and hence taking on the responsibility for monitoring for and
> responding to security updates in the pinned dependencies yourself. On
> a public index server, this is designed to cover cases where projects
> are developed and released in a coordinated fashion, and are able to
> be consumed independently (so they don't depend on each other), but
> when you combine them together, they must use consistent versions. I
> just checked, and it turns out I haven't published a version of PEP
> 459 with the "constraints" extension defined at all yet (see
> https://bitbucket.org/pypa/pypi-metadata-formats/commits/8cffbf2bacb0da8fd3394216882626e66d97bcc9),
> but there's a case to be made for allowing version compatibility
> constraints as part of that extension (it is currently aimed at
> killing off the "Supports Environments" field in the main metadata
> spec, as well as allowing the scientific community to handle ABI
> compatibility constraints for NumPy).
>
> Meta-requirements are also a good fit when distributing *applications*
> (rather than libraries or frameworks), and that's a use case more
> likely to arise on private index servers (although it's not impossible
> to do on a public index server - it would potentially make sense for
> open source server applications like graphite or sentry, for example,
> to make selective use of meta-requirements).
>
> By explicitly splitting meta requirements from normal runtime
> requirements, that allows us to change the affordances of the tools to
> nudge less experienced users in the right direction (as run_requires
> is more intuitive than meta_requires, so a lot of folks will simply
> believe version pinning isn't allowed on PyPI), while still supporting
> the more advanced use cases where version pinning actually makes sense
> (via meta_requires). The split also makes subsequent dependency audits
> easier, as it makes it clearer where the responsibility for responding
> to security updates in dependencies lies (run requires = with the
> software consumer, meta requires = with the software publisher).
>
> I'll likely add a bit more on this topic to the rationale section for
> the new semantic dependency system in PEP 426 (or perhaps just a
> reference back to this post).
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncoghlan@gmail.com   |   Brisbane, Australia

I can live with it.
_______________________________________________
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
[prev in list] [next in list] [prev in thread] [next in thread]