Chocolatey package

[ploeh]

As discussed elsewhere, Zero29 should be available via Chocolatey.

The Chocolatey package should install Zero29 in a folder and include it into PATH environment variable.

It should also be able to deal with versioning issues of FSharp.Core.

[mexx]

There is no work needed, Zero29 nuget package can be installed by cinst, simply run cinst Zero29 -source '{path to directory containing Zero.*.nupkg file}'.

The only issue I currently see that FSharp.Core must be already present on target machine.
To remove this requirement we can depend on FSharp.Core nuget package and bundle the dll with the tool.

[ploeh]

While I haven't spent a ton of time researching the versioning issues with FSharp.Core, I consistently encounter the advice not to rely on the FSharp.Core NuGet package.

[bartelink]

Any reason to avoid --standalone ?

--standalone
Specifies to produce an assembly that contains all of its dependencies so that it runs by itself without the need for additional assemblies, such as the F# library.

see MSDN

I'm guessing the effect on perf should be near neutral...

[ploeh]

The primary reason is ignorance; I didn't know about that compilation flag.

The documentation is, I think, a bit sparse, so I'd have to experiment a bit with this to see what really happens.

[medmondson]

Excuse the ignorance but why is this even a Nuget package? It appears to me that it's entirely separate command line tool from your .sln solutions

[ferventcoder]

@medmondson I think this is possibly something that would move over to Chocolatey, as that is where packages for applications and tools usually go.

[bartelink]

@ferventcoder Where do you draw the line in terms of what tools you deem "utilities" vs versionable build tools though?

If the CONTRIBUTING needs to now tell you how to install ZeroToNine from a 'utilities' source on your OS of choice, you've introduced friction into a contribution process which could previously be defined as:

1. run tests
2. up the version
3. push a PR

The paket bootstrapper straddles the line (arguably on the other side) and has fallen on trying a github release download and then falling back to NuGet.

GitVersion is available on Chocolatey, NuGet and as a gem.

[ferventcoder]

@bartelink NuGet started off as only for DLL files and later added tools related to building (such as ILMerge). You can draw a pretty good line there. When a utility is not related to the development process, it's hard to say they should belong in NuGet.

But the other side of the distinction is not as clear. Anything that is a tool/application/utility is great for Chocolatey. Even things you use to build like CMake.

GitVersion makes sense in at least two, if not all three of those places. But at the end of the day, it's anyone's preference where they want to put things.

We've always said you use NuGet to create the tools/applications/utilities you put on Chocolatey.

[ploeh]

There are other examples of shipping executable tools via NuGet. The ones I know of off the top of my head are xunit.runner.console and NuGet.CommandLine. Zero29 fits nicely into this tradition, I think.

Zero29 is strictly a development tool; actually, it's a software release tool, just like NuGet.CommandLine. I use zero29 to control versioning, and (later in my build process) nuget push to publish my NuGet packages.

To be honest, I don't see the need to involve yet another package manager in order to deal with something that's strictly about development and publication of a particular software project.

[ferventcoder]

@ploeh you are more making the case for Chocolatey, which is exactly where development tools as well as tools in general go (we also have NuGet.CommandLine). But a software release tool, I see it as a great place to be to have it on Chocolatey as well. We have other release tools there that folks are discovering - https://chocolatey.org/packages?q=tag%3Arelease

It's totally up to you. Here's why I'd suggest also pushing that EXACT SAME package to Chocolatey:

In ten seconds installed and using on the path.

[ferventcoder]

The exact same package on Chocolatey would assist in discovery and picking up more usage of your tool. If that is not something you may be looking for, that's fine. No one is requiring that you put it up over there.

[ploeh]

I left this issue open and with the jump in tag because I've nothing against publishing Zero29 on Chocolatey. I just don't have the bandwidth to do this myself... 😓

[ferventcoder]

Oh right on. :)

[bartelink]

@ferventcoder I love chocolately too, but tools like Zero29 and FAKE are intentionally cross platform. I'm not aware of Chocolatey providing this but am not exactly up to date :)

For instance one might script a build that:

1. uses Paket to pull down FAKE and Zero29 [which would imply a place like NuGet or GitHub releases tather than a tools/utils repo]
2. offers a release target within the build script which could then employ Zero29 as part of the process

The downloading on the fly aspect of the above is jsut a devil's advocate position - having successful first-time builds of code that can be pulled from a DVCS be contingent on the availability of an online service is obviously highly contentious.

I'm just pointing this out in defence of viewing a tool like Zero29 as more a development tool than a utility. But I can definitely see lots of people taking the "utility" view and hence would agree with you and Mark that it's no harm to have it in multiple places (as GitVersion does)

[ferventcoder]

@bartelink no worries. I've spent a lot of time in the past trying to explain the difference between NuGet and Chocolatey, so I tend to carry unintentional baggage into the conversation. Sorry about that @ploeh :/.

tools like Zero29 and FAKE are intentionally cross platform. I'm not aware of Chocolatey providing this but am not exactly up to date :)

Yes, Choco has been xplat since the rewrite had it's first release in March 2015. :)

having successful first-time builds of code that can be pulled from a DVCS be contingent on the availability of an online service is obviously highly contentious.

I can see that aspect. Folks tend to use appveyor to do verification of PRs, in some cases we do stuff where we are installing mingw, cmake, boost, and a whole world of tools to build a project so we can verify that the PR is good. Once we've accepted the PR, we pull things from our internal chocolatey (nuget) repository (so there isn't a contention). Here's an example - https://ci.appveyor.com/project/puppetlabs/facter/build/3.1.0.839 and https://github.com/puppetlabs/facter/blob/5e1b325d6b350d950b55fb621ac143b1e6797d53/appveyor.yml

[bartelink]

@ferventcoder Thanks for taking the time to explain - that makes a lot of sense.

Great to hear it's xplat now too. I'm consuming it via Install-Package and it's Just Working without me even taking the time to think about it much (realizing I should have remembered the xplat bit from either the DNR or PS podcasts from before the rewrite).

[ploeh]

tools like Zero29 and FAKE are intentionally cross platform

Is Zero29 cross-platform? I must admit that it's one of those tools I built a while ago, and since it Just Works™, I'm not fiddling with the code base with any regularity. I don't recall having made it cross-platform, but perhaps a contributor did that...

In any case, I think it'd be nice if Zero29 is cross-platform, so if it turns out that it isn't, I'm happy to look at a pull request 😉