I see Rob's point, but it only seems important in the case where a third party packager is somewhat blindly wrapping the msi or zip provided by the project. A good package management system would allow a level of granularity that isn't generally available in the windows environment - something like what we see with apt and Debian packages. Large bundles in windows installer form are what Windows users (including devs) have seemed to want up to now. The packaging "movement" is pushing things in a different direction. If the packager merely provides an differentway to run the msi or unzip the zip, he really isn't doing a lot.
Charlie On Sat, Feb 25, 2012 at 10:30 AM, Louis DeJardin <louis.dejar...@gmail.com> wrote: > Forwarding to this list, as it seems connected to the vnext nunit packaging > options. > > -- > Louis - sent from mobile > ________________________________ > From: Rob Reynolds > Sent: 2/25/2012 9:52 AM > To: chocolatey > Subject: [chocolatey] Guidance on packaging apps that have both a .zip/exe > and an install option AKA Starting to move towards virtual packages > > 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 > > -- > Let's get chocolatey! > > You received this message because you are subscribed to the Google > Groups "chocolatey" group. > To post to this group, send email to chocola...@googlegroups.com > To unsubscribe from this group, send email to > chocolatey+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/chocolatey?hl=en > > -- > You received this message because you are subscribed to the Google Groups > "Seattle area Alt.Net" group. > To post to this group, send email to altnetseattle@googlegroups.com. > To unsubscribe from this group, send email to > altnetseattle+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/altnetseattle?hl=en. -- You received this message because you are subscribed to the Google Groups "Seattle area Alt.Net" group. To post to this group, send email to altnetseattle@googlegroups.com. To unsubscribe from this group, send email to altnetseattle+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/altnetseattle?hl=en.
