Choco: pack - Pass arbitrary properties like nuget pack

[heaths]

What You Are Seeing?

Unlike nuget pack, I cannot pass properties to choco pack which blocks implementation of Microsoft/vswhere#30.

What is Expected?

I can pass --properties "foo=1;bar=baz;" to choco pack (using the same syntax as nuget pack for uniformity). I want to be able to build packages in either configuration for 1) testing, and 2) to make sure no one who might have rearranged content broke package build. Only our release configuration would be published, but we want to build both flavors in case devs only build one (typically debug).

[ferventcoder]

Hi @heaths - this is not NuGet, so expect differences. That said, let's switch this from a bug report to an enhancement request and get it on the priority list. Note: this issue may already exist.

[ferventcoder]

All set up as an enhancement now - and it is open for community contribution as well. :)

[heaths]

Thanks. I'm actually taking a look at implementing it now. Just wanted to get a bug open. After fixing it, could you guys push a new version soon - especially to nuget.org? (Seems you publish https://nuget.org/packages/chocolatey, if I'm not mistaken.) I can add it to my _.nuget\packages.config_ and have it pulled down with nuget restore for easy build-time acquisition.

[heaths]

Also, I checked before I opened (far from my first rodeo!) and couldn't find any current issue or PR similar.

[ferventcoder]

This may require NuGet 3.5+, which means this will be blocked by #508 - that will be a significant undertaking and is not open for community due to how much affect it will have on core choco - much testing, much rework to redo all enhancements we've made to nuget itself in all of the new places of NuGet v3+.

[heaths]

Not sure I understand the relationship. There is a package published at https://www.nuget.org/packages/chocolatey/ that has no dependencies - just basically a raw OPC container that contains your binaries. With that I can simply run nuget restore to pull it down and extract it (which I already do for a number of other packages).

[ferventcoder]

I was talking about arbitrary properties going into nuspec - if it is for fields that already exist in nuspec, you can ignore what I was talking about.

[ferventcoder]

Sorry for confusion - hard to copy parts I'm referencing when not at a computer

[heaths]

This works since you basically cloned their _nuspec_ OM (it seems - I didn't dig too deep) to add properties like WikiUrl, ProjectUrl, etc. I've also been keeping an eye on related issues regarding them persisting arbitrary properties as a bag (like many XML and JSON parsers will do for round-tripping) but figured that would take them longer than just adding supported I needed to choco to build my packages. Hopefully they do it as some point.

But, yeah, this uses existing features in nuget to pass properties as if you specified nuget pack -properties "foo=1;bar=baz" (as you probably saw in the PR). I'm more or less just passing values through (though I need to parse them in order to pass them as a dictionary to nuget).

[ferventcoder]

But, yeah, this uses existing features in nuget to pass properties as if you specified nuget pack -properties "foo=1;bar=baz" (as you probably saw in the PR). I'm more or less just passing values through (though I need to parse them in order to pass them as a dictionary to nuget).

As long as the properties translate to existing nuspec fields, I think you are fine. However if you are storing arbitrary properties, that is not supported in choco's implementation of NuGet.core:

• Allow arbitrary properties in nuspec - Issue 4260 / Commit c8ddc207
• Allow arbitrary properties on \Issue 4265 / Commit 14f07e61
• Allow propertyConstraints on dependencies - Issue 4266 / Commit 14f07e61

[ferventcoder]

storing arbitrary properties

And now I see why there is confusion. The properties element never made it into NuGet 3+ - https://github.com/NuGet/NuGet.Client/blob/870340673ba75a95407ab55ce1f46f57fe9bf25b/src/NuGet.Core/NuGet.Packaging/compiler/resources/nuspec.xsd (current dev branch)

I'm lost as to why that might be since the issues were closed as fixed for NuGet v3.0. Ideas @jeffhandley?

[jeffhandley]

I'm no longer working on NuGet and I don't know.

[heaths]

No, not storing arbitrary properties. This is to replace $variable$s within the _nuspec_ file. Nothing more. That's been supported by nuget since at least mid-v2s. I've already tested my existing code changes and it works fine. No need to update NuGet.Core for this.

[heaths]

Sorry for all the comments. I'll remove the issue reference. Don't want to rack up a bunch of commits just trying to get appveyor to work.

[ccamburn]

+1 for this. One of the nice things about nuspec files when we create nuget packages are that we can use variables for things like path to the bin folder (using $configuration$\bin) or custom id's or descriptions on packages. We often need to create multiple packages in our process, either to have ci packages, internal vs. external, packages built in debug vs. release, etc. Having a single nuspec that we can pass params into makes life much easier, instead of having different nuspecs for each.

[ferventcoder]

This is slated for vNext 👍

[ferventcoder]

This is now in the codebase, but we don't yet have an ETA on 0.10.8. It could be pretty soon (sometime in August).

[ferventcoder]

@heaths thanks again for helping to get this in, glad it turned out to be quite easy!

[ferventcoder]

Just a note that I just pushed up a beta version with this included. https://chocolatey.org/packages/chocolatey/0.10.8-beta-20170806