Open Stack

On 22 August 2015 at 09:08, Doug Hellmann <doug at doughellmann.com> wrote:
> Excerpts from Robert Collins's message of 2015-08-20 15:24:03 +1200:
>> We currently have a test where we ask if things are packaged in
>> distros. http://git.openstack.org/cgit/openstack/requirements/tree/README.rst#n268
>>
>> I think we should modify that, in two ways.
>>
>> The explanation for the question ignores a fairly large audience of
>> deployers who don't wait for distributions - so they too need to
>> package things, but unlike distributions packaging stuff is itself
>> incidental to their business, rather than being it. So I think we
>> should consider their needs too.
>>
>> Secondly, all the cases of this I've seen so far we've essentially
>> gone 'sure, fine'. I think thats because there's really nothing to
>> them.
>>
>> So I think the test should actually be something like:
>> Apply caution if it is not packaged AND packaging it is hard.
>> Things that make packaging a Python package hard:
>>  - nonstandard build systems
>>  - C dependencies that aren't already packaged
>>  - unusual licences
>>
>> E.g. things which are easy, either because they can just use existing
>> dependencies, or they're pure python, we shouldn't worry about.
>>
>> -Rob
>>
>
> I think this interpretation is fine. It's more or less what I've been
> doing anyway.
>
> Is it safe to assume that if a package is available on PyPI and can be
> installed with pip, packaging it for a distro isn't technically
> difficult? (It might be difficult due to vendoring, licensing, or some
> other issue that would be harder to test for.)

Licensing we already assess separately, anything we are ok with
(Apache2, MIT, BSD) distros and operators should fine easy.

Operators shouldn't be caring about vendoring: being on the CD train
is exactly what vendoring aims at [reliability on the assumption that
you'll upgrade all the things as fast as possible to ensure security].

Distributors probably care about vendoring, but IMO we should ignore
that. Projects that vendor do so with consideration for stability and
user experience - and even so is pretty rare in the Python space.
Distros are making a different choice - which is their right - but its
strictly additional work that has significant costs, and they've
already factored in that cost in aggregate in choosing to devendor
things.

-Rob

-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud