Describe the package management

[dscho]

There is a stub, but it needs to be fleshed out.

[dscho]

@ferventcoder I would like to ask for your help here. As you maintain the NuGet packages, and as we are considering getting away from mingw-get, would you please detail what we would need to do in order to switch to chocolatey/NuGet?

[ferventcoder]

Hi @dscho - Is this for the consumer end of Git for Windows or mSysGit?

[dscho]

@ferventcoder primarily for the end user (but remember, we need a shell and Perl with Subversion bindings, so we probably need to ship a minimal MSys).

As for msysGit: we are switching to the SDK (have a look at the org in which this ticket lives).

[ferventcoder]

@dscho As an aside - I personally love all of the tools provided in the bin folder with Git for Windows.

For the end user on Chocolatey's end, right now the state of the world is that there is a handoff - the installer is created (by your team) and the Chocolatey package (git.install) knows how to download the installer and install/upgrade Git silently. From my perspective, that is it. If there was/is a way to use mingw-get from within git, I've never used it (or at least realized I was using if it is used by git under the covers).

There is also the portable version, which the Chocolatey package (git.commandline) knows how to download and put on the PATH.

choco install git has a dependency on git.install, so things just get installed.

Are these the details you are looking for or more of an internal switch?

[dscho]

Well, the discussion revolves around the problem that Git users currently need to use a full-blown installer to upgrade Git to a new version, and if they only need, say, an upgrade of bash, they still need a complete new version of the Git installer that only upgrades the bash. So we're looking for ways to make this more efficient, in particular from a maintenance and contribution point of view.

[ferventcoder]

Ah, I see. So you are looking to use more of the Chocolatey ecosystem versus adding everything and the kitchen sink to the installer.

[ferventcoder]

I think for that, you can start to split things out and depend on git subpackages, that way you can update those out of band. Like git-bash or maybe just bash - I'm not sure if there is a package out there at the moment that is just bash.

[dscho]

@ferventcoder okay, so basically the NuGet ecosystem does not provide the packages that we would require yet... not sure we have the manpower to conjure those packages into existence.

[ferventcoder]

What I envision is a traditional route of installation, where a user can download an AIO (all in one) package (the current) and install it. And then you provide all of the subpackages that go into that AIO so each can be upgraded separately. Those would work with the current install location of git on the user system (which can be found by the registry install location).

This also allows for when the next tool has a CVE, you can be much quicker to patch just that tool.

Perhaps ultimately move away from the AIO and just provide the smaller packages, providing instructions on how to install all of them (or to use Chocolatey) - the side effect of this is that outside of Chocolatey it complicates the user experience.

[dscho]

Again... I was looking for a way to reduce the maintenance burden, not to increase it 😄

[ferventcoder]

@ferventcoder okay, so basically the NuGet ecosystem does not provide the packages that we would require yet... not sure we have the manpower to conjure those packages into existence.

Correct. Right now, I'm not sure if the ecosystem is at that level, yet.

Again... I was looking for a way to reduce the maintenance burden, not to increase it 😄

:) One thing to consider is that mingw-get will likely become part of what chocolatey can intuitively install from as well. All of the alternative sources (cygwin, python, gems, etc) will likely get better in the next incarnation of Chocolatey (which I'm just about to add back in the alternative sources for) so that they do a better job of installing the alternative pkg mgr, then installing packages from (which is currently user driven, not specified from packages themselves).

Then we'll likely enhance the nuspec that describes the package and the dependencies to allow for taking dependencies on these alternative sources, thus

 <dependencies>
  <dependency id="bash" source="mingw" />
  <depencency id="less" source="cygwin" />
</dependencies>

[ferventcoder]

That is probably about six months out at the moment.

[dscho]

Okay. So we're stuck with mingw-get for the moment, although there are already signs that mingw-get's ecosystem is dying...

[ferventcoder]

That doesn't sound good. MingW to me is better than CygWin, I'd rather see it survive over anything else for Linux tools coming to Windows. :/

[dscho]

Okay, I got around to try and use MSys2 and Pacman, and updated the Wiki accordingly.