Contributing guidelines

All packages in this repo should be in conformity with the official package creation guidelines.

Source Files

• Consider installing the EditorConfig plugin for your favorite editor.
• Note the part about character encodings of the official guidelines and make sure you always use UTF-8 without BOM for the *.nuspec files and with BOM for the *.ps1 files and not any other legacy encodings.
• Indentation for *.nuspec and *.ps1 files: 2 spaces
• Keep the package source files clean and remove obsolete or outdated code and unnecessary comments.
• Comment non-obvious code so that others can inspect the package more easily to understand what it does.
• Limit code/script files (e.g. ps1-files) to 100 characters per line (except lines with URLs).
• Add a chocolateyUninstall.ps1 file based for instance on this template.

Package icons

• Packages added to this repository must have a package icon if one is available.
• When it comes to package icons, follow the package icon guidelines.
• The file name of the icon should be the same as the package ID. If the icon is already available in the repository, use the existing one instead. Don’t put duplicate icons into the repository.

Optional

• Use http://cdn.rawgit.com/Thilas/chocolatey-packages/{{commitHash}}/icons/{{packageID}}.{{fileExtension}} as iconUrl. Replace {{commitHash}} with the actual hash of the commit where you added the icon. This makes necessary that adding packages to the repository consists of at least two commits (one for adding the icon and another for the iconUrl, using the previous commit hash as part of the iconUrl).
• Updating icons also requires to update the commit hash in the iconUrl, otherwise it will still point to the older version of the icon.

Automatic packages

• Refer to automatic packages page for a guide on how to create automatic packages.
• If you want to add an automatic package to this repository, export its Ketarin job to automatic/{{packageID}}/{{packageID}}.ketarin.xml.
• Make sure that you don’t commit the files generated by chocopkgup in automatic/_output/{{packageID}}.
• The <TargetPath> property in the Ketarin jobs should always be the hardcoded path: C:\CODE\_work\.
• The <Name> property should always be identical to the package ID. Also respect the casing.

Fixing automatic packages

To fix an existing Ketarin job, import it into your Ketarin instance, make the fixes and export it again to the same XML job file, then commit.

If you notice that an automatic package in the repository is broken (e.g. if it’s uninstallable due to an error), proceed as follows:

1. Fix the affected package source files in automatic/{{packageID}}/*.
2. Import the corresponding {{packageID}}.ketarin.xml into your Ketarin instance.
3. The automatic/_output/{{packageID}}/ folder should not contain a folder named after the version that your Ketarin job will output. If there’s already a folder named after that temporarily rename it, so that chocopkgup can store the output in a new folder.
4. In Ketarin, highlight the package and select “force download”.
5. Chocopkgup will then create a folder called automatic/_output/{{packageID}}/{{version}}. Rename the version using the bugfix notation. If for example the broken package has v1.0.0, use 1.0.0.yyyymmdd for the fixed version.
6. Use the same fixed version in the nuspec file of the package.
7. Remove the nupkg file and build the package again.
8. Test the fixed package.
9. Revert the renamed folder in step 3 to its original name.
10. Commit and make sure you also check in the fixed version in _output/{{packageID}}.

Self-contained packages

Self-contained packages are packages that include the packaged software in the nupkg instead of downloading it. Do not check in binary files of packaged software into this repository, because it will bloat this repository too much.

Desktop automation tool

If the package needs to perform tasks that cannot be done with command line switches, e.g. clicking away a prompt during installation that cannot be suppressed like for example in the dropbox package, you can use AutoHotkey. Make autohotkey.portable a dependency of the package. Prefer AutoHotkey over AutoIt, because AutoHotkey is more lightweight, FOSS and more actively developed than AutoIt.

Remember that the desktop automation script must work on every locale available for Windows, so be careful when using strings of text of window in the script that could be different in another language.