-
Notifications
You must be signed in to change notification settings - Fork 10
Publishing
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?
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.
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
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
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
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.
See creating a tarball, a complicated example from the user perspective; you have to provide the hooks that the users will need.