No project description provided
BUYER BEWARE: This project is still in very early stages. Its architecture will drastically change from day to day as I experiment, make mistakes, and implement the lessons learned. I also cannot make any guarantees that the entire codebase will always work. Bugs abound. Having said that, if you like to browse incomplete code and gain an understanding of how a project is designed, this might just be the thing for you!
I work with infrastructure. The kind of infrastructure where you have a bunch of baremetal machines that don't have an OS installed. Where the only access you have at the onset are their BMC IPs. In that case, I need some sort of machine provisioning tool that is agentless. Truly agentless, not just Ansible agentless.
In other situations, I might need to set up a CI/CD cluster. Now if you're like me, you'd prefer to configure this cluster on top of as thin a technology stack as possible (read: just bare OSes). The reason for this is because if you want to deploy your CI/CD cluster on top of the best whiz-bang technology stack, such as Kubernetes, you have to ensure that you have a CI/CD infrastructure in place before you do...but that's exactly what's missing and what we're trying to deploy! Again, what's needed here is an agentless infrastructure automation tool.
In both situations, I've found Ansible usable for a time. However, after years of using it, I've come to find it cumbersome. With its supposed-declarative YAML-based DSL slowly transforming into a turing-complete language. At this point one wonders why we don't just use an already proper language itself like, oh I don't know, Python?
This is what brought be to pyinfra. This project builds on top of pyinfra's good-enough implementation. It is an attempt at replicating the Ansible project structure that I've been using for years as exemplified in another project called relaxdiego/cicd.
Why Didn't You Just Use Terraform?
I have ample experience with Terraform in the past too and I've maintained the "Terraform for provisioning, Ansible for configuration" dichotomy for some time. I maintain that stand for this project but have changed it to "Terraform for provisioning, Aircraft for configuration."
This project doesn't add wrappers around pyinfra, so once you get the hang
of how to use pyinfra,
then you can easily move on to some of the stuff I do in the
of this project.
Once you're comfortable with pyinfra and you start browsing the
dir, you'll see that all I'm doing is adding pyinfra packaged deploys
that you can use in your operations files. I've also created some pydantic
models that go with the packaged deploys to help with validating inventory
data. Anyway, check out the
examples/ directory before I keep blabbering
- Python 3
Prepare Your Python Environment (pyenv style; one-time only)
You will need two additional dependencies for this style:
Once the above dependencies are installed, do the following:
- Install an isolated environment for your preferred Python version.
python_version=<YOUR-PREFERRED-PYTHON-VERSION> pyenv install --enable-shared $python_version
NOTE: For more available versions, run
pyenv install --list
- Create a virtualenv for this project
pyenv virtualenv $python_version aircraft
- Add a
.python-versionfile to this project dir
cat >.python-version<<EOF aircrat $python_version EOF
Your newly created virtualenv should now be automatically activated if your prompt changed to the following:
or, should you happen to be using dotfiles.relaxdiego.com, if it changed to the following
... via 🐍 <YOUR-PREFERRED-PYTHON-VERSION> (aircraft)
Notice the things in parentheses that corresponds to the virtualenv you created
in the previous step. This is thanks to the coordination of pyenv-virtualenv and
.python-version file in the rootdir of this project.
cd .. or
cd anywhere else outside your project directory, the virtualenv
will automatically be deactivated. When you
cd back into the project dir, the
virtualenv will automatically be activated.
Prepare Your Python Environment (venv style)
If you'd rather manage your virtualenv manually, this section is for you. Create your virtual environment:
python3 -m venv ./venv
Activate it in every shell session where you intend to run make or the unit tests
Install The Dependencies
Install all development and runtime dependencies.
WARNING: Make sure you are using a virtualenv before running this command. Since it
uses pip-sync to install dependencies, it will remove any package that is not
listed in either
setup.py. If you followed the steps
in any of the Prepare Your Development Environment sections above, then you
should be in good shape.
Adding A Development Dependency
- Add it to
requirements-dev.inand then run make:
echo "foo" >> requirements-dev.in make dependencies
This will create
requirements-dev.txt and then install all dependencies
requirements-dev.txt. Both files should now be updated and the
foopackage installed in your local machine. Make sure to commit both files to the repo to let your teammates know of the new dependency.
git add requirements-dev.* git commit -m "Add foo to requirements-dev.txt" git push origin
Adding A Runtime Dependency
- Add it to
runtime_requirementslist in setup.py and then run:
This will create
requirements.txt and then install all dependencies
requirements.txt. We ignore the latter since this is a library project which may be used with different versions of its dependencues at development and run time.
git add setup.py git commit -m "Add bar to requirements" git push origin
Testing and Building the Charm
After any change in the library, you want to ensure that all unit tests pass before building it. This can be easily done by running:
make test build
Viewing the Coverage Report
To view the coverage report, run the tests first and then run:
This will run a simple web server on port 5000 that will serve the files
in the auto-generated
htmlcov/ directory. You may leave this server running
in a separate session as you run the tests so that you can just switch back
to the browser and hit refresh to see the changes to your coverage down to
the line of code.
Other Make Goals
make help or check out the contents of
Running the Tests in Multiple Python Versions
More often than not you want to be able to support more than one version of Python. This is where tox comes in. Just run the following to get test results for all Python versions listed in tox.ini's envlist config option
Release history Release notifications | RSS feed
Download the file for your platform. If you're not sure which to choose, learn more about installing packages.
|Filename, size||File type||Python version||Upload date||Hashes|
|Filename, size aircraft-0.5.2.tar.gz (32.0 kB)||File type Source||Python version None||Upload date||Hashes View|