System level belongs to apt, indeed. But @newky was quite explicit here:
If you’re not a Python person, then some explanation may be in order. A virtualenv is a project-specific area where pip can install Python packages, which is owned by the user and belongs to a project or projects. It overrides the system Python package list, but does not overwrite it; it’s a separate folder, which doesn’t touch your system-installed packages. It is the perfect solution here (almost as good as npm, which does the same thing but even better, or PHP’s composer). Using pipwith a virtualenv is absolutely the right thing to do, and does not interfere with apt at all. It also means that if you ever see the phrase sudo pip anywhere at all, you should feel free to mock whoever said it, because you never ever need to use a language-specific package manager as root, and if you do then you are wrong and stupid and should be stuffed head-first into a barrel of leeches.
Anyway, yes, virtualenvs are one fine solution. But it gets quite confusing since some python packages are used system-wide, some only by some users, and they can pull in many dependencies each, so that gets hard to maintain for a regular user (non-developer). I remember encountering a little hassle when building Sage, the math toolkit based on python. It uses a hundred other packages or so, many of them being the python-science-whatever stuff. When working on a new python project that would surely be diffferent, just like with npm/JS when I write stuff there (I’m a web dev). But what happens when your window manager is written in JS, like nwm? I’d want that system-wide, it wouldn’t be part of a project. I could imagine setting up a virtualenv for it and putting all the users that need access to it in a certain group. But that sounds like unnecessary work somehow.
That is why I find it confusing - sometimes I might need a package that I would only find through pip, and I’m pretty sure I already used it thusly at some point. With sudo of course.
Gentoo luckily has tools that take care of keeping system-wide python and perl packages clean and up-to-date (python-updater and perl-cleaner) which come in very handy. And I would guess there is also a tool for ruby, but I don’t use any ruby stuff so I cannot tell. Are there similar tools in the distros?
I would expect, though I know I’m being optimistic, that whatever software requires those packages would list them as a dependency - like any other library - and your package manager would take care of installing them in the system-wide location.
When you’re developing then pip/cpan/etc. would install them in your user/project specific location and when you ultimately bundle up your app (for personal use or public distribution) you list all those dependencies.
I know the reality isn’t quite there yet - having just tried to use git send-email to submit patches to Arch’s pacman (for paccache) - but that’s how I hope everyone would do it.
One common note among all distributions is that they don’t have enough manpower. Distribution of software is a problem on Linux and it is a problem by choice. And yet everyone likes their own package management and their own package format. Knowing very well that they will fail to supply latest updates of software to its users.
[exaggeration] Is it reasonable to expect upstream to provide packages for 5 versions of Ubuntu 7 versions of Debian 8 versions of OpenSUSE and 10 versions of Fedora [/exaggeration]. The package management is broken on Linux by distributions and their internal politics.
When I develop for Android I know that APIs are going to be around for 5 years from now. I know that there is only single class for notifications. I don’t have to use Appindicators for Ubuntu, KStatusNotifierItems for Plasma 5 and Message Tray for Gnome. I know that one apk will install on 100% of devices. I know that Android 5.0 is going to add things to previous Android versions. It’s not like Plasma 5 comes and obsoletes KDE 4. There is 100% guarantee that all extensions will break when a future version of Gnome is released.
Development and distribution on Linux is very tricky. Unless you are doing it for free.
I agree with this, knowing this is the main strength and weakness of libre softwares: you have the choice. Given that choice, you can decide to use an existing solution, to develop your own from scratch or to fork an existing one.
But this is because Android is not really an open source project. You don’t really have the choice in the APIs you’re gonna use. Moreover, Android was released in 2008, which makes it a very young product. Nothing indicates that things won’t break at some point in a near future. Google was very careful to build things atop of each others in order to attract developers because they knew they needed apps to attract customers, but now Android is the major OS in the mobile industry, they could very well decide to break compatibility and force developers to address that issue themselves.
This is a convenience statement. Who is stopping you from writing libraries to provide whatever APIs you want. They don’t accept your code but Cyanogen Guys have added plenty of their own code in Cyanogen Mod. People blame Google for abondoning open source apps but what is stopping stewards of open source to release their own open source alternatives to Play store or F-droid.
This is not really fair. There are two primary package management systems on Linux, .deb. and .rpm, and most distros pick one of those. Now, I agree that they run their own archives, and I agree that they bite off more than they chew, but most people don’t rebuild their own package management systems.
Now, Ubuntu has decided to do this with .click, but this is mostly to rectify the problems that you have highlighted.
Agreed, but you are comparing apples and oranges. Android is two things: an operating system and a development platform. I agree that if you write your app for one operating system and one developer platform it works like a charm, but that would be the same if you decided to write your app specifically for the GNOME platform and targeted Fedora.
The only difference here is the APIs being supported for so long, and while GNOME (or Linux desktops) may not support it that long, generally APIs are supported for a long period of time.
This is why I think you are comparing apples and oranges - Linux is a collection of operating systems and developer platforms, and Android is one operating system and developer platform.
