Stephen’s tool to manage projects spread across repositories. https://github.com/dev-pipeline/dev-pipeline
Up until now, all dependency ordering in dev-pipeline is managed using a function that provides a valid sequence as a Python list. The simplified code is basically this:
build_order = resolve(self.targets, self.components)
for target in build_order:
for task in self._tasks:
task(target)This has been fine for initial versions, but it’s not very flexible.
Continue readingSo my project management software has a new alpha release. Originally this version was just going to have a few small features that a friend needed for his use-cases that required changes to core functionality (his front-end doesn’t require anything akin to a configure step).
The specific features I wanted to support for 0.3.0 were:
Continue readingSo I had dev-pipeline in a position where it met every one of my current needs: I could fetch sources, I could build, and I could generate dependency graphs. I was happy and my projects ran well.
Continue readingEvery good work of software starts by scratching a developer’s personal itch.
Eric Raymond, The Cathedral and the Bazaar
Like most developers, I’m a creature of habit. I like git for source control, so I use git to track changes in pretty much everything, even if they’re non-source (e.g., configuration files, my resume, and even my hobbyist writing). It’s mostly a matter of sticking with patterns I know and embracing muscle memory; with git not only get version tracking, but I can easily back my work up to tons of places with one command.
Continue readingA while ago I mentioned dev-pipeline, and I kept hacking away and improving the software. I didn’t think about it too much since it met my needs (or was easy to add the missing feature), but it came up at work the other day and I decided to see just how complex the project I was managing was. Since dev-pipeline learned how to generate dependency graphs in dot format, this was easy.
Continue readingSub-modules (or if you prefer mercurial, sub-repositories) are a popular method of dealing with complex dependencies spread across multiple repositories. In theory, you can develop libraries while developing multiple applications that use them (or more libraries), and you don’t have to deal with setting up your build environment beyond what it takes to do a simple build.
In practice they lead to lots of issues.
Continue reading