Support "Software Is Already Installed" before *ANY* dependencies are processed

[DarwinJS]

In regard to an existing pattern - SCCM 2012 has this ability - saves a massive amount of unnecessary downloading over low bandwidth clients.

1. Evaluate a meta-data stored criteria based on non-chocolatey stuff (files, regkey, etc) for whether the software is already installed - do this as the first step before any dependencies are installed or any downloads occur.
2. If the criteria passes, mark the package as installed in choco.

Here is the anti-pattern that I have to implement now (and will be in the next version visualstudio2013testagents as I am just fitting it with logic to check if the agents are already there due to full visual studio being installed.):

1. Resolve and install dependencies (such as virtual clone drive)
2. Run the package script and
3. ONLY IF the packager coded a check for the software already existing, mark the package as installed if the software is already present
4. The software sometimes being present by virtual of a totally different software installer that was not installed by Chocolatey.

Putting the "already installed" criteria in the meta data would have the advantage of not soiling the system with dependencies (especially those just used for installation) and it would raise the quality of packages since packagers would be more like to code the "already installed" criteria rather than missing the fact it is a best practice to have it in the code logic.

Use cases include:

• Very standard dependencies (Visual C runtimes, .NET, etc).
• Packages that install stuff that is also part of other software. For example the visual studio test agents do not need to be installed if visual studio itself is already installed because they are included. I should have to depend on the chocolatey package to have delivered visual studio full in order to appropriately handle the situation. *) Installation of dependencies only used during install (e.g. imdisk / virtual clone drive for ISO based installs).

[ferventcoder]

Terminology is a bit off. I think you mean support software is already installed prior to dependencies being processed.

[DarwinJS]

No I mean the core software of the package => it may be there due to another install - such as Visual Studio Agents being present because full visual studio was installed outside of Choco.

[DarwinJS]

I see what you mean - corrected the title.

[ferventcoder]

We've added some starting bits to this - it will be opt in by package - but there are some rough edges that need to be shaved off first in addition to a transitional period.

Looking this whole thing over, we've covered most of these ideas by other issues - all of those would need to come together before this would be coherent. I'll pick apart each piece in a minute. :)

[DarwinJS]

Sounds good.

My thoughts always tack toward

1. Tapping into the wisdom of existing patterns as they cover use cases Chocolatey may not have the scale for yet (SCCM is over 20 years old and services multiple millions of clients) and
2. Toward raising best practices to a level where they are hard to overlook - for example, do much more in .nuspec rather than best practice code in choco templates that is frequently overlooked and left out.

[ferventcoder]

1. Sometimes present by virtual of a totally different piece of software, not installed by Chocolatey.

And sometimes the dependency is already present by software installed by other packages - you can't win them all - so the expectation is to support virtuals, conflicts and replaces (like other packages managers do).

A dependency on a virtual, like a PDF reader would be resolved by adobe reader, but it could also be resolved by sumatrapdf. Either of those installed would meet the requirement. However trying to account for all of those different possibilities in each package for wild variances even outside of Chocolatey is not a direction we would approach any more than the limited scope of registry searches.

Conflicts and replaces are about packages that have issues with other packages - for instance upgrading from jre7 to jre8 - jre8 would replace jre7.

[ferventcoder]

1. Tapping into the wisdom of existing patterns as they cover use cases Chocolatey may not have the scale for yet (SCCM is over 10 years old and services multiple millions of clients) and

I'm thinking in a similar vein, except the concepts from actual package management tools, as that is the direction of what Chocolatey is and should emulate - when something like SCCM conflicts directly with package management, it must be evaluated on which way the distinction should go.

[ferventcoder]

Debian has been around for over 20 years so they know a thing or two about package management.

[ferventcoder]

1. Toward raising best practices to a level where they are hard to overlook - for example, do much more in .nuspec rather than best practice code in choco templates that is frequently overlooked and left out.

Totally in the plans. #325 is one of these.

[DarwinJS]

And sometimes the dependency is already present by software installed by other packages - you can't win them all - so the expectation is to support virtuals, conflicts and replaces (like other packages managers do).

If the dependencies had the same support built-in - they would benefit too - it would cascade.

A dependency on a virtual, like a PDF reader would be resolved by adobe reader, but it could also be resolved by sumatrapdf. Either of those installed would meet the requirement. However trying to account for all of those different possibilities in each package for wild variances even outside of Chocolatey is not a direction we would approach any more than the limited scope of registry searches.

These are less frequent - I am talking about direct hard dependencies where the benefit is clear

[DarwinJS]

Debian has been around for over 20 years so they know a thing or two about package management.

I am not dissing other platforms. That not with standing the chances of servicing low bandwidth clients increases astronomically with managing millions of laptop / desktop end points. So in the specific area of optimizations around bandwidth - debian won't have such an advantage.

[ferventcoder]

The anti-pattern that I have to implement now (and will be in the next version visualstudio2013testagents as I am just fitting it with logic to check if the agents are already there due to full visual studio being installed.):

1. Resolve and install dependencies (such as virtual clone drive)

As we plus things up, the dependency itself will decide whether it is installed or not and not do anything - this will be handled by Chocolatey itself.

1. Run the package script and
2. ONLY IF the packager coded a check for the software already existing, mark the package as installed if the software is already present

Right now this is true. We have plans for this to become part of core.

[ferventcoder]

So in the specific area of optimizations around bandwidth

#454

[ferventcoder]

But yeah, I think we are in agreement that putting more into the nuspec is where to go - it makes things a bit more declarative and lowers the need for a chocolateyInstall in the most common situations. Win all over the place.

[DarwinJS]

I have some ideas on #454 - added them to that thread.