Proposal to reduce anti-bundling requirements

[Adam Williamson]

On Sat, 2015-09-12 at 16:26 +0200, Reindl Harald wrote:

> bad idea to start the mess and when it goes wrong point somewhere
> else
> 
> i hear that all the time when something breaks terrible my workflows
> and 
> at the end of the day nobody feels responsible - well, i tell you
> what i 
> do: ignore pip, cpan & co as well as any software which requires me
> to 
> touch it and finally Fedora if it goes that way

I really don't think pip and cpan are the best examples to think about
here. As I said, both python and perl are reasonably well set up to
allow distribution packaging, and as ecosystems they have generally
fairly decent standards of library/package/module/whatever-you-want-to
-call it maintenance. I don't see a lot of examples of projects with no
releases, or layouts completely unsuitable for system-wide
installation, or anything like that.

A much better example is PHP. PHP does not have a reasonable official
class loading system baked into the interpreter which is compatible
with distribution packaging, nope. PHP has a complicated history of
shitty practices and conventions. The basic upshot is that you can't
just take a 'normal' PHP codebase, dump it on a system where all its
dependencies are installed systemwide, and expect it to use them, like
you generally can with a Python or perl codebase. PHP just doesn't have
that infrastructure. Whatever the details, the big picture is that the
codebase will basically be expecting to find and load its bundled
copies, and if they're not there it will throw a fit.

You *can* work around this, but it is almost entirely without exception
not what upstream expects and not what upstream cares about: it
requires messy downstream modifications of one kind or another.

The modern-day 'Standard Way' to build PHP projects against external
dependencies - Composer/Packagist - is *expressly designed* to
implement bundling and disregard system libraries. It has a very crappy
and inadequate, disabled-by-default option to load system copies of
libraries that follow one specific layout, but many many libraries do
not, and unbundling those is *always* a downstream-only change that
upstream does not care about helping.

There's been a kind of self-reinforcing spiral of shittiness around
this stuff in PHP for years. Here's the very short summary:

* PHP doesn't have a clear infrastructure/set of conventions for
loading modules and classes, so...
* People just throw them in their source trees and load them ad hoc,
so...
* Module developers don't give a crap about sensible versioning and
stable APIs (because projects just bundle their dependencies anyway),
so...
* The ecosystem rapidly becomes a mess of projects using incompatible
variants on the same modules, so everyone involved in it comes to
believe that it's futile/impossible to share modules in any case, so...
* They build a big machine for bundling dependencies and call it
Composer, and that's where we are now.

If your experience in this stuff is limited to actual shared objects
and perl and python modules, you are *only* seeing the *best possible*
story for distribution packaging. Other ecosystems are far, far worse. 
PHP is the one I'm most familiar with, but I'm given to understand
others are very similar. Javascript, for instance, is the same mess as
PHP only probably even worse.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net