>I'm personally getting so sick of all the package managers I have to use, I'm more and more inclined to not use a technology if it comes with a package management system.

So, you're better off with a technology that needs you to manually manage packages and dependencies?

>Seriously, what is going on with the OS vendors?

What about them? What do they have to do with Node, QT, Python, and other communities with package managers?

OS X has the App Store for OS X apps, Windows has something similar, Linux distros have package managers for their userlands. Other projects have nothing to do with OSes schedules...

> So, you're better off with a technology that needs you to manually manage packages and dependencies?

No, you're better off having a single well-integrated system package manager. Once you start stuffing shit into system directories behind its back you lose all oversight. You can't even answer a simple questions such as "where did this file in /bin come from?" anymore. You can't tell the package manager "verify all installed files in system directories with the checksums listed in the package managers database" because the package manager doesn't know all the files.

I agree with GP, I avoid projects that require me to use a third party package manager if at all possible. If only because none of them seem to understand the reason for code signing.

>No, you're better off having a single well-integrated system package manager.

And wait for MS and Apple and your distro to keep up with ALL upstream changes? And have them approve what goes in there? Yeah, good luck with that...

>Once you start stuffing shit into system directories behind its back you lose all oversight. You can't even answer a simple questions such as "where did this file in /bin come from?" anymore.

You'd be surprised. E.g. brew files are in the Cellar dir, npm modules are in node_modules, global pip files are in their own folder, etc.

No package manager I use (and I use several, and all are quite popular) messes with system directories.

>You'd be surprised. E.g. brew files are in the Cellar dir, npm modules are in node_modules, global pip files are in their own folder, etc.

Yeah, you're pretty competent at remembering all that, because you have to, over and over again, re-build this ontology... probably as part of a job or profession. Therefore "its good for you".

But, outside that box, is a world where applications, developers, the operating system .. and most important of all: users, don't have to hire people such as yourself to maintain all that gluck. And in that world, the OS and Apps guys, when they build Frameworks, don't make the mistake of -DRY/NIH/RTW'ing themselves, over and over and over again (I count 4 in your list, but there are many, many more sorts of this kind of thing) .. ad infinitum.

It is a huge mess, modern software development. There is nothing efficient, effective, or 'intelligent' about everyone having their own idea about how to add packages to a system. We learn this, every single time some language-/tech-/stack-dejour forks off their own little mind about how this all should be done.

Its because there isn't such attention being paid by the people who assemble the operating systems, about the needs of .. what admittedly becomes a huge reason to stay 'stuck' on the OS. Once you get it all set up. And have a team of monkeys to keep it from falling over, just because someone did an install somewhere, touched a .file accidentally, didn't quite properly set up a BOGUS_ENV before doing configure, etc. and etc. and /etc.

In case of Linux: the kernel alone does not make an OS, so if you consider the various distributions of Linux OS'es, like Debian for example: Each (well the large ones) distribution comes with their own package management tools.

So currently the "state of the art" is: Create a package for each OS (which means multiple OS'es of flavour "Linux").

I really wish their was a generic tool that would input a source tree and output packages for the most common package management systems.

Anyone?

You could have a look at CPack: https://cmake.org/Wiki/CMake:Packaging_With_CPack It was created to be used with the C++ build system CMake, but can be used without it too. I use it to automatically build debian packages from Jenkins, but it also supports tarballs, RPMs, NSIS (Windows), PackageMaker (OS X), and cygwin packages. Hope this helps a bit!

That's precisely the point: we already have package managers. Its just 'unfashionable' to use them.

What I would do if my language needed package management: write an abstraction for whatever package managers exist on the platform I'm targeting. So my 'package manager' would just be a smart shell around apt-get, or yum, or whatever.

Okay, this looks like an idea ripe for the attention ..

How exactly do you see it done by the OS vendors ? Should they try to support every conceivable programming language out there ? Should they force every language to use a certain package format ?

Until languages reach a stage where they have totally transparent interoperability - which is the ability to use a library in your language regardless of the language the library was written in - OS vendors have a monumental (impossible) task on their hands.

Windows tried this with COM and ActiveX and I don't think that succeeded entirely.

Things like CLR or JVM are a partial solution, but you can't expect a C++ programmer to work with the JVM or a C guy to make his hack compatible with CLR.

I guess the way we have it right now is the natural "best" way. Let's hope someone somewhere gets enlightened and enlightens everyone else.

I had hoped, by now, that OS vendors would have evolved a system of managing packages in a filesystem that was standardized, easily portable across operating systems, and easy to implement with a little forethought from anyone wishing to package their apps for the system or add support for the package/bundle in their language as a first-class implementation. In many ways we have this: at least in the Games world, where we can't expect the user to do package management to just play a game, we've got things like good ol' .zip files masquerading as filesystems, and thus .. our game is really a little OS with its own universe. The other end of the scale.

But its really, really hard, it seems, to get everyone to agree to these kinds of standards and share things across the filesystem in a way that is easily maintainable by real people as well as automated systems. I don't truly believe all this new school of thought, either, about filesystems having to go away - to me this is just a cop-out by folks who should be taking responsibility for teaching people what a filesystem is (since we have so many of them) before we start throwing them away and replacing them with .. something .. which inevitably doesn't solve any of the filesystem problems, but does mean less code has to be maintained.

Which is why I think language-people do this "NIH"'ification of the problem: nobody is enforcing any rules, so Langage-X has to have its own way of laying things out, providing common code, isolating things into common/routine layouts, and so on.

It truly is, for me at least, that if your language requires package management, its broken and isn't any better than any of the other umpteen languages that preceded yours, no matter how sexy it is, and which also has "package management".

The whole are is just broken and isn't fixed yet. I don't know all the answers, but I have a feeling a good start might be "build an OS, an execution environment, and a user interface using one language and one language only, and make all sub-systems of that OS utilize a standard, built-in, intelligently designed means of handling dependency graphs for user sub-modules".