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 ".commandline" suffix.
If you would take a quick look at 7zip (http://chocolatey.org/packages?q=7zip), you will notice there are three packages here.
- 7zip is what will ultimately be a virtual package
- 7zip.install is the package name for a package that uses a native installer (i.e. MSI, exe)
- 7zip.commandline is the package name for a package that has an executable / downloads & unpacks an archive / etc
7Zip right now is taking a dependency on 7zip.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.commandline' '7zip.install'
You will notice I put the ".commandline" ahead of ".install". In the end, I think the behavior of a virtual package should default to a command line version. Why? There are folks that do not have administrative access to their machines. 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.
That said, the default will be the one on the leftmost side. You are beholden to the community in justifying why you didn't put the command line version first if you decide not to in the virtual package. But chocolatey won't constrain you on that because you may have a really good reason.
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?
Original Discussion: http://groups.google.com/group/chocolatey/browse_thread/thread/a1d208b022dfc30f