Publishing

Publishing

"Design" your package

You need to determine who the users of your package are.

How you define your package is dependent upon how it is expected to be used. Is it just to be used as a simple set of files or environment variables? Is it a library? An application? Are you going to set up a default set of variables/files or are you going to require users to specify a set?

Mechanics

Command-line basics

Publishing is accomplished using the --publish and --publish-local options.

If you're experimenting with the creation of your package, you should use --publish-local, which unsurprisingly doesn't make the result public, but only accessible to yourself. (Note, if you use this option, you will need to use --update-if-missing/-m and not --update/-u to access packages from another local working directory.)

The --publish option checks whether a package with the same name and version already exists and won't overwrite it unless the --force option is specified.

Otherwise the two options behave identically.

Specifying the contents

You can create the package definition entirely from the command-line or from a file. You should read the description of package definition files, even if you're only going to use the command-line.

If all you need is a default configuration with a few files and environment variables, you can do it entirely from the command-line:

fig --publish some-package/some-version --add 'CLASSPATH=@/stuff.jar' --resource stuff.jar --include junit/4.1 --include jetlang/0.2.7

This is equivalent to a package definition file containing

resource stuff.jar
config default
    add CLASSPATH=@/stuff.jar
    include junit/4.1
    include jetlang/0.2.7
end

The following options are equivalent to the statements by the same name: --add, --append, --set, --include, --override, --archive, and --resource. Just as with the statements in a package definition file, the order of --archive, --resource, and --override options is not significant, but the order of --add, --append, --set, and --include options is. So the result of running

fig --publish package/version --set FOO=BAR --include thingy/v2.3

may or may not be materially different from running

fig --publish package/version --include thingy/v2.3 --set FOO=BAR

If you need multiple or non-"default" config blocks or you need a retrieve or command, you will need to use a package definition file. You can use the --file option to specify the package contents (e.g. if you're publishing multiple packages from a single source directory) or just allow the default "package.fig" file to be used.

fig --publish service/3.23 --file service.fig
fig --publish service-client/3.23 --file service-client.fig

Scenarios

A simple example with just environment variables

Say you've got some service provided from different hosts based upon geographic location. You could provide connectivity information with a package defined as

config europe
    set SERVICE_HOST=10.1.34.243
    set SERVICE_PORT=28934
end

config australasia
    set SERVICE_HOST=10.1.37.25
    set SERVICE_PORT=33062
end

config africa
    set SERVICE_HOST=10.1.12.239
    set SERVICE_PORT=52917
end

and your users could take advantage of this like

fig service/342.233:australasia -- some command

Simple open source library

A bundling of log4cplus.

resource log4cplus-1.0.4.1-rc2/package/**/*

config default
    add INCLUDEPATH=@/log4cplus-1.0.4.1-rc2/package/include//log4cplus/
    add LIBPATH=@/log4cplus-1.0.4.1-rc2/package/lib/liblog4cplus-1.0.so.4.0.0
    add LIBPATH=@/log4cplus-1.0.4.1-rc2/package/lib/liblog4cplus-1.0.so.4
    add LIBPATH=@/log4cplus-1.0.4.1-rc2/package/lib/liblog4cplus.so
    add LIBPATH=@/log4cplus-1.0.4.1-rc2/package/lib/liblog4cplus.a
end

Bundled application

resource whatever
config default
    set BAND=KMFDM
    add LIBPATH=@/lib
    command "do stuff"
end

After publishing this simply invoking fig -u package/version will "do stuff".

A real world example of this was where a particular setup was required prior to running a bundled version of Chromium with a particular set of command-line options.

Supporting users that need to get everything outside of Fig

See creating a tarball, a complicated example from the user perspective; you have to provide the hooks that the users will need.