> TLDR;
> 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 use 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?
> ____
> Rob
> "Be passionate in all you do"
> http://devlicio.us/blogs/rob_reynolds
> http://ferventcoder.com
> http://twitter.com/ferventcoder
