BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News NuPack, OpenWrap, and CoApp – A Roundup on Package Managers for .NET/Windows

NuPack, OpenWrap, and CoApp – A Roundup on Package Managers for .NET/Windows

This item in japanese

Bookmarks

Microsoft has released NuPack CTP 1, an open source package manager for .NET. OpenWrap is another package manager for .NET with many similarities and some differences. CoApp is a package manager for Windows featuring updates and support for multiple languages like C, C++, .NET, PHP, Python, Perl.

NuPack

NuPack is offering the ability to add .NET libraries to VS projects through a visual interface or a command line. Basically, NuPack relieves the developer from cores like finding the right package, downloading, verifying the hash, unzipping, adding a reference to the library, and editing the web.config files. Instead of all those manual steps, the developer will chose a project from the NuPack Package Gallery from within Visual Studio, and NuPack will download the package along with all its dependencies, and will install it, adding all references and editing the web.config file. Those who prefer the command line are able to perform the same tasks from the prompt since NuPack is integrated with PowerShell.

NuPack is bundled with ASP.NET MVC 3 Beta and will be later completely integrated into VS. NuPack accesses the available projects by downloading an Atom feed from CodePlex, but a better place is looked after. Phil Haack, a Senior Program Manager with the ASP.NET Team, has detailed some of the requirements he plans to be implemented for the NuPack gallery:

1. A default site for hosting packages and providing the feed. This would be our equivalent to rubygems.org. Anyone else can have their own feed (like CodePlex.com) but this is the one the tool looks at by default.

2. No approval process. If you have an account on the site, you can add packages.

3. Packages can be hosted on the site, or pointed to on another site. Thus the site itself can host your package (except for GPLv3) OR you can point the site to your package hosted elsewhere (much like Web Platform Installer). We're giving developers a choice here.

NuPack has been accepted by Outercurve Foundation (formerly CodePlex Foundation) as part of the ASP.NET Gallery, being open to anyone who wants to contribute.

OpenWrap

InfoQ informed on a similar project, OpenWrap, that was announced in May 2010. We wanted to find out how OpenWrap is impacted by NuPack’s release, and what is the overall status of the project, so we talked to Sebastien Lambla, one of its main committers.

InfoQ: How do you comment on NuPack? How does it affect OpenWrap’s development?

SL: NuPack solves a large subset of the problems OpenWrap attempts to solve, but on nearly every implementation detail takes a different approach. It’s good to see some competition in this space, but there’s room for better alternatives and more “opinioned” ways of dealing with the problem of dependency management. OpenWrap has been under development for many, many months and is fast approaching beta status, so we’re going to continue working on it, and it will still be at the core of the next wave of OpenRasta development.

If anything, NuPack’s availability will increase the amount of OSS developers building packages, and while the formats are different, it can only be a good thing. If packages are there, versioning is taken into account, and the whole community can move forward. We’re also pressing on with implementing support for the NuPack packaging format, although it will be clearly marked as a legacy format, and converted upon retrieval.

InfoQ: Are you still planning on continuing development on OpenWrap, now that NuPack, backed by Microsoft, is available?

SL: Yes, absolutely. This changes nothing to our roadmap, except maybe that we’ll add support for their packaging format, as a legacy package, on .net platforms that support the office packaging format in use.

While [we miss] the developers that have joined forces with Microsoft a few weeks before the release, we have a codebase already, and abandoning it to back the Microsoft project would not make much sense. People are already using it, building on top of it, and I do not see a feature set that could just replace what we have built.

InfoQ: How is OpenWrap different from NuPack? Does it offer or planned to offer basically the same functionality, or is it supposed to be different? If you are still continuing developing OpenWrap, what is the roadmap?

SL: OpenWrap integrates itself at a different level of the architecture, we inject ourselves as part of the build process rather than update a project manually. OpenWrap is also very much focused on runtime dependency deployment, not only for assemblies, but for anything an application may need at runtime. This translates in a different way of managing dependencies that in the long run should be more efficient.

A lot of what NuPack does looks similar to OpenWrap at this stage because the scope of our first release is a limited feature set that was announced in May. Microsoft obviously came to the same feature set definition when they started the development on NuPack at the end of April. Call it converging evolution.

OpenWrap also has a concept of system-wide repository, and per-project OpenWrap versioning. In the long run, both of those features are going to enable a whole bunch of scenarios that are much more interesting than just referencing assemblies or JavaScript files.

OpenWrap uses itself both for building new versions and for deployment. The system has been self-bootstrapped for a while now, and has really helped increase the efficiency of the code.

Our roadmap includes inclusion of test runners, per-environment dependencies, meta packages, build system independence, unreleased versions support, and of course a custom web site available for deployment that can serve dependencies inside and outside of the firewall.

We also continue supporting both .net 3.5 and .net 4.0, as well as VS 2008 and VS 2010. And we have really exciting features that will make OpenWrap a very compelling experience for developers in the coming weeks.

Of course we don’t have the marketing money and full-time people on the payroll to write blog entries and web sites, but we’ll get there. And as we are not part of the Microsoft release cycles, we will not suffer the shipping train lockdown that will invariably impact the NuPack team as soon as MVC3 gets closer to a release.

CoApp

We also wanted to know what is going on with another Microsoft-supported project called CoApp, a project packager for Windows, so we contacted Garrett Serack, the CoApp project initiator, asking for the current status and what relationship his project has with NuPack. Serack makes the point that while NuPack targets only .NET developers and one project at a time, CoApp has a much wider scope:

CoApp handles package management for Software Developers and Users (end users, admins, etc). Packages are installed at a system level, intending to be shared between components and applications without limiting their scope to a single project at a time.

CoApp includes an update service that allows all the software on the system to be kept up to date with security and feature updates to packages.

CoApp is also being developed for use by Native applications (written in C/C++) as well as .NET, Python, PHP, Perl, etc. 

He also mentioned that they will probably benefit from NuPack by adopting and adapting some of the NuPack code into CoApp and probably supporting “the use of NuPack packages for developers using CoApp to publish software.”

Serack said that CoApp is alive and well with about 40 committers working in teams or individually on different parts of the project “client, developer tools, publisher tools, core libraries and internal engine”, planning for a beta release in early 2011.

CoApp has also been accepted by the Outercurve Foundation, but in the System Infrastructure and Integration Gallery, a gallery with interoperability and integration goals for the Windows platform.

Rate this Article

Adoption
Style

BT