96

There are some programming languages for which exist a package management system:

Is there any other languages with such systems? What about C and C++? (that's the main question!) Why there are no such systems for them? And isn't creating packages for yum, apt-get or other general package management systems better?

Improve this question
3
  • 3
    Objective-C has Cocoapods (very similar to ruby gems and bundler). So kind of odd that C++ doesn't have something similar. Perhaps because C++ is less homogenous. Apple provides more standard stuff to build packages on top off. In C++ one can hardly agree on what string class to use.
    – Erik Engheim
    Jun 12, 2013 at 21:22
  • I would just like to point out that the package managers from other languages are not perfect. For example, in Ruby Gems one may often encounter a gem that doesn't work for a specific OS (more than likely Windows) and the documentation doesn't tell you it doesn't work for that OS.
    – Travis Pessetto
    Aug 15, 2013 at 17:53
  • stackoverflow.com/questions/7266097/…
    – Ciro Santilli OurBigBook.com
    Aug 5, 2015 at 8:00

5 Answers 5

Reset to default
36

Actually some people (of noticeable boost fame) are working hard to create and establish such a system called Ryppl. It is hard to establish such a System for C++, because it has no single player which can dictate it. --UPDATE: Unfortunately it is abandonned.

On your second question, a normal package manager (besides not being cross platform) does not handle the specific needs of developers.

Improve this answer
11
  • 2
    Wow, I wonder how they are going to fight 20 years of "We don't need a package manager!"
    – TheLQ
    Oct 20, 2012 at 18:28
  • 8
    Well, them being of Boost fame, I'll give them the benefit of the doubt and take a peek. Boost, after all, is quite amazing :)
    – Onno
    Oct 22, 2012 at 6:46
  • 2
    @TheLQ - I don't think there's anything to fight other than that no one has previously presented a workable solution. There's no 'we don't need not stink'n package manager' there's 'No one's shown me anything that seems useful'. The former can be difficult to get around, but the latter is simple: just present something that actually help devs do their job.
    – Michael Kohne
    Oct 23, 2012 at 13:50
  • 1
    This answer should be updated: 1) Ryppl is a dead project, even it's website is dead. 2) Other projects (commercial or not) like cpm have spawn recently so there is a lot of work being done for getting a package manager for C++. 3) I believe that there will be no winner until modules are in the language and one of the tools manage to exploit that to the fullest.
    – Klaim
    Jan 3, 2015 at 21:34
  • 2
    @Klaim re:{until modules are in the language} as far as I understand modules doesn't make things easiler, it's just a syntax sugar for the #include command. It will not solve the main problem of versioning/downloading/installing/compatibility/cross-platformic C++ issues.
    – ruslo
    Nov 3, 2015 at 11:13
21

I think that a problem with C and even more with C++ is that they are more heterogeneous languages: even though these languages are standardized there exist different compilers with different options or different sets of supported features. E.g., I remember posting a question about C++ on stack overflow with an example that was working perfectly on GCC / Linux and someone immediately posted an answer saying that my code was non-standard.

Having a package system like the ones mentioned in the question would imply having a common language and libraries that are supported uniformly by all major compilers on all common operating systems. E.g., you do not want to download a C++ package and discover that it won't compile on your version of compiler X because it was developed on compiler Y on another operating system.

I could imagine that a system based on make and configure scripts (as commonly found on Linux, cygwin and other Unix flavors) could work. But why should Visual Studio users adopt it? The same is valid if one started a package system based on Microsoft Compilers (and libraries).

The fact that C++ is a fast evolving language and its standards always take some time before being fully supported by all compilers does not alleviate the problem.

Improve this answer
2
  • 1
    Well, you can write portable C++, or you can write to a specific toolchain. Your choice, and nothing wrong with either, though not doing the former when there's no advantage to the latter is somewhat suboptimal.
    – Deduplicator
    Nov 11, 2015 at 20:51
  • 3
    There is portable C and C++. If a library can't be installed in a standalone way by an installer easily, it should be remade. It's perfectly possible to accomplish this. Even in NodeJS many modules fail to build on Windows, but it still manages to exist, so occasional build issues are not a problem, and having a centralized package manager streamlines feedback from users and makes it more incentive to deal with issues.
    – Dmytro
    Jul 17, 2016 at 1:44
5

I think the questions we need to ask in order to answer yours are "What do other languages/ecosystems gain from having their own centralized package repository?" and "Does this apply to C/C++?"

I feel the answer to the first question has something to do with the initial promotion of a new language: the early adopters want to make it as easy as possible for newcomers to enter the ecosystem, acquire useful, tested code and contribute back their own. For obvious reasons, the "usage graph" always has a single root - the creator(s) of the language. There's usually one reference implementation (at least initially) and therefore any code you might want to share has to conform to it.

This makes it easy to create packages that just download and compile. Certainly, had C or C++ been introduced in 2013, their communities could have followed a similar evolutionary path, but they hadn't and there's no one single prevailing toolchain to apply a package manager to. This makes the implementation of such a program too troublesome to be worth the hassle. (should you make users choose between libfoo-gcc and libfoo-vs? Do you leave it up to the packager to resolve? Or the build process? If so, how is a package any different than a straight-up tarball?)

So to sum up my answer to the first question, I think the pattern of creating package managers serves mostly to drive adoption.

With that in mind, I think it's fairly easy to see why no single system has risen to fulfill this need - because the need doesn't exist for C and C++ programmers. What does constitute a problem for the C and C++ community (or any programmer community, really) is the need originally implied: to distribute, keep up to date and contribute back code. This has been solved many times by different people with varying degrees of success, and indeed one system is gaining significant market share: git (and some other systems before that).

Basically when the problems differ, the solutions look different too, but IMHO the difference between typing gem install and git clone is moot.

Improve this answer
2
  • 6
    "What do other languages/ecosystems gain from having their own centralized package repository?". You need to be a very very experienced developer to start downloading packages and trusting them to work properly with your software. Having a package manager allows people to just start using packages instead of dealing with context sensitive build instructions/so on. I myself can't figure out how to get boost to work on MinGW, so I end up writing much of it's functionality myself over and over, instead of just using it. It's silly not to have.
    – Dmytro
    Jul 17, 2016 at 1:46
  • 2
    Not having to fight with various install/build scripts and flags would be a great win.
    – themihai
    Nov 15, 2017 at 10:33
3

There is a little confusion in this question. The above mentioned software manage extensions for specific programming languages. They provide libraries and source code that afterwards can be used in you program with your programming language of choice.

While general system level package mangers usually provide binary packages that can be used regardless of the application. They are more oriented at the system and user. Of course, system level package management systems like Aptitude, rpm, Entropy can provide any package, being it binary or source code. That's why you will find in them most of the extensions you would install with ... Gem for example.

Than, what you mentioned as Yum and Apt-get or Rigo are just user interfaces for the package management systems below them.

One more for the list o programming languages:

  • Composer and Pear for PHP
Improve this answer
2
  • Yeah, definitely. What I was thinking about when writting last three questions?
    – m0nhawk
    Oct 20, 2012 at 9:37
  • The issue is that these packages get globally rather than locally, and bundling dependancies of your project into a single folder is very difficult. This means that a project might work on your system but as soon as you put it on another system you need to remember what it depends on and get all of them and put them in exact places your project expects them to be. This process is hell. An example of this is GTK, easy to globally install, hard to locally install.
    – Dmytro
    Jul 17, 2016 at 1:48
0

I realize this is not a cross-platform solution, but it should be added to the mix.

CoApp recently announced support for C++ package management using NuGet: http://blog.nuget.org/20130426/native-support.html

This currently only works with the Visual Studio compiler, but there have been many requests to get this working on other platforms.

Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.