The 0.8.3 release adds an INI_DIR variable that will be substituted into values in the configuration file, allowing for paths to be specified relative to the config file. It turned out that this was a feature I wanted, to keep the bundled data somewhat more local than requiring a fixed path under HOME.

While testing this change, I discovered that the Python 3 line prior to 3.3.4 had a bug in the tarfile module. When using the module exactly as I am (with an externally-provided file object and gzip compression), the tar data doesn’t get written into the gzip stream on disk.

That was reported as issue 20238 and fixed by the final releases of 3.3.4 and 3.4.0, while 2.7 has never been affected.

Due to the widespread availability of 2.7 on systems that packaged affected versions of Python, I decided the pragmatic path would be to recommend Python 2 on those systems and raise the Python 3 version requirement to 3.3.4. I haven’t isolated the fix by diffing Python releases, nor do I know what I would need to patch over in order to work around it.

This release is available as source on github, and as a wheel on PyPI.

Any and all bugs should be reported to the issue tracker on github.

The 0.8.2 release adds a setup.py and associated machinery, meaning that cloud-maker is now on PyPI.

Any and all bugs should be reported to the issue tracker on github.

The 0.8.1 release adds official support for Python 2.7 to cloud-maker, enabling it to run on the system python installed with OS X. Reports on the Internet suggest that this covers at least as far back as Lion, forward through El Capitan. (I can’t find an extensive history, but Lion released a year after 2.7.0, which in turn came after Snow Leopard.)

This change should also make it more readily available to Linux users, as python 2 is typically installed as the default /usr/bin/python executable.

If there are any issues with this release, please send them to github.

In other news, ‘v0.8.0’ and ‘v0.8.1’ tags have been added to the repository.

I didn’t actually test the OVA export I got from fedora2ova, but cloud-maker has been pushed to my cloud-maker repo. Happy Wily Werewolf Release Day!

The repo is currently designed to run in-place with either of these forms:

python -m make_provisioner --help
python . provision --help

I’d like to add a setup.py so it can be published to PyPI and abandoned, but that’s not ready yet.

When we last left off, I had sketched out a config file for fedora-pack, then neglected it when I finally accepted that Perl is dying.

Seven months later, fedora-pack is undergoing a rewrite to Python. It’s equally widespread (or easy to install) and includes a ton of batteries. I’ve always liked that.

But that’s only half the change. I’ve been trying to simplify and streamline the code, to make it more straightforward even at the expense of some flexibility and testability—there are, after all, no tests, no extensions, and no users. As far as I know.

That’s resulted in a rather different codebase, because of two realizations:

1. At work, I don’t use the multi-version capability. What if make_provisioner just installs the platform’s default version? It would have to know a lot less about distros and versions.
2. At work, our bundled scripts install our own necessary packages (such as git) in addition to the core languages. What if make_provisioner doesn’t bother offering package preinstallation? On the one side of the process is cloud-init, if preinstallation is important. On the other, the runner script can install its own choice of language packages. Now make_provisioner doesn’t even have to care about distros (or features or packages) at all, as long as it can have a distro-agnostic SFX stub.

Things seem to be going well so far; expect a code dump on github by November. I want to use cloud-maker for work’s AMI builder, instead of a hacked fedora-pack fork, and the Ubuntu 15.10 release will be a good time to change that.

I mentioned last post that I was thinking of going with “a config file of some sort.” Plans have formed to use INI format, and the parser is written. (Between the desires to be pure-perl all the way down and to keep embed size down, I didn’t find any pre-written parsers that suited me on CPAN.)

So, it’s probably going to end up something like this:

; we basically just use this for supervisord, no venv needed
[python2]
min_version = 2.7
with_virtualenv = 0

; legacy app can’t handle `carton exec`
[perl]
with_carton = 0

[php]
min_version=5.4

[main]
install = "php perl python2" ; known to fedora-pack
add_packages = "php5-fpm libmoose-perl" ; known to apt/yum

As a bonus, the sections organize the options so that languages can define their own options fully independently, without having to avoid naming conflicts in the CLI options.

fedora-pack will continue to install all the per-language options by default, since actually using them is best practice, as I understand things.

I’ve noticed that python-pip and virtualenv packages on Ubuntu Utopic have similar dependencies—but the latter is on *-whl packages and the former is not. Since I use Python but not virtualenv in my own server build, it ‘would be nice’ to skip the automatic installation of it by fedora-pack.

Of course, in order to support such a thing, fedora-pack clearly needs more options for finer control. Yet, it seems like the global option parser isn’t the perfect place for language-related options, so the App::FedoraPack::System class tree may spawn some additional argument-related functions.

I may finally go with a config file of some sort. The command line is getting unwieldy already.

I didn’t really have a place to pre-announce changes to my repos, so I made one.

This spawned a small adventure through staticgen in order to find a static site generator. I really wanted it to run on Win64, because I have to fire up a VM to update propaganda since it was built for a POSIX world. For style points, I went for ones written in languages I already have installed.

So after trying Hugo, Sculpin, Phrozn, and Pelican, the last one happened to be a winner.

I’m kind of sad Hugo didn’t work out, since it seems fast and nicely built, but I couldn’t get it to understand about generating pages with relative URLs so that I could preview them with the theme applying properly.

One of the PHP frameworks wasn’t PHAR-aware, and tried to use DIRECTORY_SEPARATOR to build the path of an XML file to load… but that creates an invalid URL when DIRECTORY_SEPARATOR isn’t ‘/’.

Pelican has its warts, to be sure (there’s no real themes gallery, just a bunch of githubs with screenshots of varying quality) but it’s working and I can work with it. And I’m not locked into keeping all my pages on github because Octopress is secretly managing the repository for me; I wrote my own publish script. Although magic is convenient, it turns out that I always want to understand the next layer down. Even if it’s just a small bit of knowledge I never use, it’s comforting to know I wouldn’t be hopelessly adrift if GitHub Pages closed down.

Anyway, look for future updates about my repositories here on sapphirecat.github.io. I want to get away from the “randomly dump breaking changes on an unsuspecting world” model of development.