Chocolatey - Guidance on Packaging Apps with Both an Install and Executable/Zip Option

Update (2013/07/22): Deprecated ".app"/".tool" in favor of ".install"/".portable" for better understanding on inspection. Previously the guidance was ".install"/".commandline" so if you run into that they all refer to the same thing.

One of the thoughts I've been considering recently with chocolatey is consistency with packages and naming conventions as chocolatey continues to grow. It's fine to name packages by the app/tool name, that's both intuitive and expected. What I am more interested in is when an application has multiple installation options (ie. an MSI and a ZIP). It can become confusing for people to install these when they don't know what they are getting if they call a package that has both. If you start with one that has a .zip and later they release an MSI (nodejs anyone?), what do you call the package that installs the MSI? Do you keep around the executable? Do you rename the original package in response to the other option? Is there a third option?

One Option

If there is only one option available, you are fine to make the package name the same as the application/tool. This makes it intuitive and reduces confusion. 

Multiple Options

To start putting together guidance on this and alleviate confusion, I see that we would move forward in these cases with three packages. One with no suffix, one with ".install" suffix, and one with ".portable" suffix. This brings in chocolatey's idea of applications versus non-installed tools ( https://github.com/chocolatey/chocolatey/wiki/ChocolateyFAQs - apps are installed on the system, portables are not).

If you would take a quick look at Instant EyeDropper ( http://chocolatey.org/packages?q=instanteyedropper ), you will notice there are three packages here. (Note: These are not the actual names, as this post has been updated to what they should be named)
  • InstantEyeDropper is what will ultimately be a virtual package
  • InstantEyeDropper.install is the package name for a package that uses a native installer (i.e. MSI, exe)
  • InstantEyeDropper.portable is the package name for a package that has an executable / downloads & unpacks an archive / etc
InstantEyeDropper right now is taking a dependency on  InstantEyeDropper.install (which makes it a meta package). When virtual packages (see Virtual Packages below) are ready, that dependency will be removed and the chocolateyinstall.ps1 file will look something like the following (this is not definitive of what it will look like though):
 Install-VirtualPackage '7zip.install' '7zip.portable'
You will notice I put the ".install" ahead of ".portable". In the end, I think the behavior of a virtual package should default to the installed application. Why? It works really well for Windows. Application authors put a lot into creating native installers so that you will have everything setup just as they had intended for you to get them setup.
There are folks that do not have administrative access to their machines. This is where portables come in. Chocolatey is really nice for them because they can install and use chocolatey without ever needing to assert administrative privileges. Marcel Hoyer (https://twitter.com/pixelplastic) first proposed the idea of being able to use chocolatey without administrative privileges. Him and I took pains to make chocolatey work for these scenarios. This did complicate chocolatey a little bit for the package maker, but in the end I think it is a really good thing. As a person inspecting a package to decide whether to install or not, they can see every point that the package maker mentioned they needed administrative privileges. 

App Now has Multiple Options

When an application/tool moves to where it has multiple options, like an installer it didn't used to have, that's when it is time to break the package out to a virtual (meta for now until virtual is available) and create the other two packages with the correct suffixes as outlined in the guidance above.

Virtual Packages

For those confused about the idea of a virtual package, it allows folks to say I need to take a dependency on a PDFReader. PDFReader becomes a virtual package that does nothing other than point to all of the different pdf readers available. When someone installs the package that has a dependency on PDFReader, chocolatey looks at the virtual options and sees you have adobereader installed (one of the options in the list). So it moves on because you have met the virtual package requirements. If you have foxitreader installed, it moves on. Otherwise it picks the first item in the virtual tree and installs it as the default. More information? https://github.com/chocolatey/chocolatey/issues/7

Virtual Packages vs Meta Packages

A meta package is one that points to other packages. If you think of a package that does nothing more than take on dependencies to other packages, that is a meta package. A virtual package is like a meta package, except it has the concept of optional dependencies.

Ending Thoughts

This seems to be on the surface the best way to provide an intuitive user experience. There may be some things we learn along the way and adjust this as we go. If you are a package owner and you have packages that have both options, you may want to start getting them into this format. I myself have some work to do in this aspect.
Thoughts?

 


Posted 02-25-2012 11:35 AM by Rob Reynolds
Filed under: , , , ,

[Advertisement]

Comments

Mike Chaliy wrote re: Chocolatey - Guidance on Packaging Apps with Both an Install and Executable/Zip Option
on 03-17-2012 2:31 PM

What is the point to have 7zip.install at all? I do not understand. In some cases xxx.install could do more work, for example add file associations. But GUI installers kill chocolatey frictionless experience. May be it's better to focus on xdeployable versions?

I love how ruby, python, sublime was installed on my computer. I do not really like how GIT installs; it presents UI but does not really give any options.

About The CodeBetter.Com Blog Network
CodeBetter.Com FAQ

Our Mission

Advertisers should contact Brendan

Subscribe
Google Reader or Homepage

del.icio.us CodeBetter.com Latest Items
Add to My Yahoo!
Subscribe with Bloglines
Subscribe in NewsGator Online
Subscribe with myFeedster
Add to My AOL
Furl CodeBetter.com Latest Items
Subscribe in Rojo

Member Projects
DimeCasts.Net - Derik Whittaker

Friends of Devlicio.us
Red-Gate Tools For SQL and .NET

NDepend

SlickEdit
 
SmartInspect .NET Logging
NGEDIT: ViEmu and Codekana
LiteAccounting.Com
DevExpress
Fixx
NHibernate Profiler
Unfuddle
Balsamiq Mockups
Scrumy
JetBrains - ReSharper
Umbraco
NServiceBus
RavenDb
Web Sequence Diagrams
Ducksboard<-- NEW Friend!

 



Site Copyright © 2007 CodeBetter.Com
Content Copyright Individual Bloggers

 

Community Server (Commercial Edition)