Comparison of Application Level Package Managers

I have to work with a lot (9) of different package managers at my daily work at VersionEye. Part of our mission is it to make manual updating of dependencies extinct, because it’s a manual and time consuming task which nobody enjoys. That’s why we are building a notification system for open source software libraries to make Continuous Updating easy and fun. And since we support several programming languages – 8 at this point! – I get to write crawlers and parsers for all of them. To give you a better overview over the strengths and weaknesses of these package managers, I picked the most popular one for each language and will compare them. The contenders are:

  • RubyGems / Bundler (Ruby)
  • PIP / PyPI (Python)
  • Packagist / Composer (PHP)
  • NPM (Node.JS)
  • Bower (JS, CSS, HTML)
  • CocoaPods (Objective-C)
  • Maven (Java)
  • Lein (Clojure)

Comparison Matrix

Here are the results of my comparison.

Comparison of Package Managers

You can read the complete article on the VersionEye Blog and follow the discussion on hacker news and Reddit.

Minimum Stability

The PHP Package Manager Composer has a very cool Feature, called minimum-stability.  That defines the minimun stability for wildcard versions. Let’s say you define this in your composer.json file:

"symfony/finder" : "2.2.*"

By default the minimum stability is “stable”. That means the package manager will look for the newest version in the “2.2.” branch, which is stable. If you want to have the newest dev version you can redefine the minimum stability for this package:

"symfony/finder" : "2.2.*@dev"

In that case you would get the newest development & unstable version from the “2.2.” branch. Possible stability tags are “@dev”, “@RC”, “@stable”, “@beta” and “@alpha”.

minimum-stability

 

VersionEye does now understand the minimum stability tags from composer and can handle it. But it’s an early implementation. Your Feedback is welcome!

Updating an existing VersionEye project via API

The VersionEye API enables you to create a project via the API. You just need to send your project file via POST to this endpoint “/v1/projects.json” and VersionEye creates a new project for that and returns a JSON with the used libraries and the information if they are outdated.

There is already an AddOn for the Symfony Deverloper Toolbar:

https://github.com/mattsches/VersionEyeBundle

versioneyebundle_screenshot

And 1 for the Zend Dev. Toolbar:

https://github.com/Ocramius/VersionEyeModule

This modules are sending your composer.json file to the VersionEye server. Unfortunately the first version created with every post a new project at VersionEye. That is not the desired behavior. We added a new Endpoint to the API, which enables the API developer to update an existing project.

The process now looks like this. The first time you upload the composer.json file via POST to this resource: “/v1/projects.json“. In the response you get back an “project_key” for the project at VersionEye. Next time you send the composer.json file via POST to this new resource: “/v1/projects/{project_key}.json“.

Screen Shot 2013-03-18 at 4.06.24 PM

The new Endpoint “/v1/projects/{project_key}.json” doesn’t create a new project. It only updates an existing project. Please use this in future to update an existing project.

VersionEye now supports custom repositories for Composer

Yesterday night I pushed a new version online. Up to know we supported only simple composer.json files like this here:

{
  "require": {
    "symfony/symfony": "2.0.7",
    "symfony/doctrine-bundle" : "*",
    "symfony/process" : "2.0.*",
    "symfony/browser-kit" : "!= 2.0.6",
    "symfony/security-bundle" : ">=2.0.7",
    "symfony/locale" : "<=2.0.7",
    "symfony/yaml": "<2.0.8",
    "symfony/http-kernel": ">2.0.6",
    "twig/twig" : ">=1.9.1,<2.0.0",
    "doctrine/common" : ">2.2 , <2.4",
    "symfony/console" : ">=2.0.0, <2.0.10, !=2.0.6"
  }
}

If you refered to a package that is not on packagist.org than we displayed it as unknown. But since yesterday VersionEye supports custom repositories. Here is an example:

{
  "name": "till/wtfdate",
  "description": "A WIP library to provide a somewhat API-compatible replacement for Zend_Date.",
  "license": "BSD-2-Clause",
  "repositories": [
   {
     "type": "package",
     "package": {
       "name": "zendframework/zendframework1-dl",
       "version": "1.12.1",
       "dist": {
         "url": "https://packages.zendframework.com/releases/ZendFramework-1.12.1/ZendFramework-1.12.1-minimal.zip",
         "type": "zip"
       }
     }
   }
 ],
 "autoload": {
   "classmap": [ "src/", "tests/Wtf"]
 },
 "require-dev": {
   "zendframework/zendframework1-dl": "1.12.1"
 }
}

VersionEye now recognises the custom repository and doesn’t display zendframework1-dl as unknown dependency. It displays it as known dependency and as up-to-date.

Screen Shot 2013-02-14 at 10.10.03 PM

Let me know how it works for you. I looking forward to your feedback.

http://www.versioneye.com

Getting a list of all Licenses in a Project

In a regular project you are using a handfull Software Libraries. Every Library in your project can use a different license. To get a list of all licenses which are used in your project can be difficult. You can double check the license for every single library in your project manually. But that is time intensive and a pain in the ass!

VersionEye is offering a quick solution for that. You can get the license list in less than 1 minute. After your login you are in “My Projects”. Click the link “Add New Project” in the left nav bar, to create a new project.

Screen Shot 2013-02-04 at 5.40.07 PM

Simply upload a project file. A pom.xml, Gemfile, composer.json, package.json, dependency.gradle or another supported file with your dependencies. After the upload you will see a tab with all the dependencies.

Screen Shot 2013-02-04 at 5.40.53 PM

Simply click on the “License” tab to see all licenses in this project. And here it is.

Screen Shot 2013-02-04 at 5.41.17 PM

In this example most Libraries are using the MIT License. Some of them are under “Ruby” license and for 1 Library VersionEye was not able to detect a license.

It’s that simple. Let me know if you have questions to this.

PHP User Group FFM

Yesterday night I went to the PHP User Group in Frankfurt am Main. It was at the CoWorking space “Die Zentrale“. Here is their Twitter channel: https://twitter.com/phpugffm.

Marco Pivetta did a great talk about Proxies. Marco is contributing to several famous projects in the PHP world. For example doctrine2, zf2 and Symfony. In his talk he explained the Proxy pattern in general and showed different uses cases for them. For example Lazy Loading, AOP or just hiding optimisation and init code. Very interesting stuff. Most of this topics I know already from the Java World. PHP is getting more serious. It becomes more Java like. Not sure if I like that.

I did a talk about VersionEye and Continuous Updating. I showed very quickly how the software development changed in the past 10 years and what is missing, from my point of view. The feedback to VersionEye was very good and productive. I got new ideas and motivation to continue with the project. Many Thanks for that.

phpugffm-2013-01-18

The PHP UG FFM is a bunch of funny guys. Very open minded and always ready to try out new things. I will come back.

Many thanks to DMR Solutions. The company is specialised into the LAMP stack. They build cool stuff on top of PHP, JavaScript and MySQL. DMR payed the food last night. Many Thanks for that.