Currently, AFAIK, one needs to fork propellor repo, add its own configuration and compile propellor binary from all the source tree. It would be handy and more modular to allow one to have a propellor configuration linked to propellor as a library, hosted on hackage.
Unusual as it is for propellor's configuration git repo to include the full source code to propellor, I like this approach. It lets users change any existing property that is not generic enough, or makes assumptions they don't like, or needs porting to their OS of choice.
But still, propellor is on hackage, as a library. It can be used that way if you want to.
I don't think that any of propellor's code cares how it's distributed, except for src/wrapper.hs (which cabal will install as ~/.cabal/bin/propellor), which sets up the ~/.propellor/ repository. You can bypass using that wrapper if you like, and cabal install propellor and create your own ~/.propellor/ repository containing only your own config.hs, and build and use propellor that way.
Where that approach becomes a problem is that propellor --spin currently relies on propellor's Makefile being in the repository, when bootstrapping propellor on a remote host. So you'll need to include a copy of that in your repo for --spin to work. I'd like to get rid of the need for the Makefile. (Only the build and deps targets are used by --spin.)
Ok, I got --spin to not use the Makefile any more. So with the 2.2.0 release, if you want to make ~/.propellor contain only a config.hs file and a foo.cabal file, that will work. The cabal file would contain something like:
Apologies for wrong information, I did not check if propellor was on hackage. Anyway, thanks a lot for caring to "fix" that, will give it a try this week and keep you posted.
Thanks a lot
SImply because 2.2.0 had not been released yet. (UNRELEASED in changelog..)