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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
