James Walker

James Walker

Web Developer

ipm dev blog, Part 4 – Significant progress!

Published on Thursday November 16 2017 at 19:10 in ipm dev blog

It's two weeks since I last wrote about my work on ipm, but over the past few days I've made some quite significant progress and now have the application core fully implemented ready for features to be layered on top. The app's now well on the way to a v0.1.0 release.

Application core runtime

The main application runtime is in main.py. The runtime(...) method is given the command specified by the user, the additional command line arguments associated with it and the working directory path for the current project. The com package is imported, which in turn imports all the individual commands (under /com) and makes them available under the module namespace. Now all we need to do, is check the command is valid (exists inside the com.commands whitelist) and its class can be found under the com namespace. We instantiate the command class, passing the working directory and arguments, and call run(...) to start execution!

View the file on GitHub - also see linked imports for more details.

Base command class

The base command class, Command in /comc.py, is extended by all the commands available in the program (under /com). It's a simple interface which has two methods, a constructor (to instantiate the class with the current working directory and the runtime args/kwargs), and run(...), which as explained above, is implemented by descendants as the entrypoint for their execution.

View the file on GitHub

Migrating project versions

Another major component I've implemented this week is a basic migration engine. In the future, updated program versions might incorporate project file schema changes or new features that have to be enabled for a project. We already save the application version with each project file, so projects know what version of ipm created them. Now at runtime, we check to see whether the two versions are identical, and if not, the user has to run the ipm_upgrade command to upgrade their project.

This command uses the migration (/migration) package to work out how many versions ahead the app is of the project file and then determine any migrations to run. These are defined similarly to commands, under the migration package and extending Migration in /migration.py. The migrations specified in migrations.migrations for each version will then be executed in-turn, so each new program version can include code to modify projects and it can be confident the incoming project definition is in the format it expects. After all the migrations are run, the ipm_upgrade command writes the current ipm version to the project file, thus completing the upgrade procedure. For the details I recommend you see the code.

View the file on GitHub - also see linked imports for more details.

Other changes

I've made a few other changes this week that evolve the project towards being a more complete usable application. These include the finished implementation of the init command, the addition of a strings module to contain output strings for the app and a work-in-progress build script using cx_Freeze. Unfortunately it seems cx_Freeze has changed a little since I last used it, and I can't get the app to build in the latest version after creating a build script modelled on ones I've written for previous cx_Freeze releases! This will be rectified over the weekend as I implement the rest of the app's features and prepare for a basic initial release.

Conclusion: Week 5

Over the past few days I've made the most progress on ipm since I started work on the project. There's now a functioning application runtime shell and support for defining and executing commands. The project loading/saving infrastructure is fully in-place. Now it's just time to actually add in the first commands and bits of functionality! Possibly, I might be able to release built packages of v0.1.0 before the end of this week! You can access the project over on GitHub.