mkdocs path Migrating DevTools projects from Sphinx to MkDocs. The good Natively supported by RTD Best theme for documentation material-docsVery actively maintained Also commercial plans and features Python based

As part of the effort to revive molecule project some drastic measures were put in place. Unmaintained drivers archived on January 5th, 2023: openstack, goss, libvirt, alicloud, vmware, digitalocean, kubevirt, lxd, inspec. Anyone wanting to revive and maintain one of these will have to make a pull request against molecule-plugins repository. The relatively active drivers were moved to molecule-plugins repository, where we expected them to be maintained by the community. Which drivers should we still see in addition to delegated? azure docker containers

Operating System src pie title Operating System "windows" : 1993 "linux" : 2729 "macos": 2488 Flavours src

Current online offline Future - running modes realtime # vs extension mode, really fast quick # from the CLI

That is an early draft, so please add comments or correct errors directly. Keep in mind that your role is to prevent new bug introduction or lowering the existing code quality. As a reviewer you are there not to prevent or delay a change but to help it succeed. Avoid mirroring other reviewers. You are not adding much value if you wait for other to act act first and only agree with them. If you do not find yourself able to review a particular change, just mention it via a comment and remove yourself from the reviewers list, potentially mentioning those that should be able to do it.

There is a change at https://review.opendev.org/c/zuul/zuul-jobs/+/807702 which is changing the default tox arguments to add "--skip-missing-interpreters false". This overrides the value from tox.ini file and disallow tox from using another python version than the requested one. The goal of this change is to prevent accidents where some project endup running tox in CI and believe that these jobs are testing one version of python but in fact another version is used instead. We think that this has the potential to affect only users of jobs with parent: tox. Users that are using tox-py3* zuul-jobs are not affected because we force tox to run using that specific python version. We will wait two weeks before merging this change, so people would have time to adapt their configurations.

When building python libraries a developer does only want to declare the compatibility range of the runtime dependencies. This ensures that consumers can make use of future patched dependencies. Still when it comes to testing always installing the bleading edge versions published to the pypa.org registry is a recipe for breaking your pipelines. Most of the bugs introduced by new packages published on pypa are usually fixed in few days. As you probably do not want to pay the price of being the early adopter you may like the idea of controlling the test dependecies and upgrading them only when you want. Python developers can learn here from JavaScript world where you get pinned dependencies insidepackage-lock.json while having compatibility ranges defined in package.json. Using pip-compile utility, which is part of pip-tools package one can easily produce lock files, very similar with the result of pip freeze. The difference is that these can be produced without creating a virtualenv and that they can be nicely annotated in order to document from where which dependency comes from.

Adam He is new to Ansible and he never contributed content to Ansible. This does not mean he lack tech skills. Goals Learn how to use Ansible Motivations Frustrations

test matrix (current) platform, backend, guest (test): macos - vbox alpine centos8 - libvirt alpine (init_scenario, default)

Note that his describes the model after __init__ cleaning (now imports look much workse than this) Another goal is to limit the amount of code we import from Ansible in order to avoid potential breakages. graph LR; __main__-->runner __main__-->rules __main__-->utils __main__-->formatters-->ansible

During the last year the setup.py was silently removed from ansible-lint project. This had a side-effect that made impossible to perform editable installs of the project, something that works very fine with other ansible projects. Editable installs are essential for anyone that does development and contributions. Without -e mode, making changes to a python library becomes a serious inconvenience. Developer has to repackage and reinstall the library before running any code again. Even debugging becomes a stuggle as you often discover that the code you run is not the one you modified. ansible-lint is the first python package I encountered that removed setup.py. The deprecation of setup.py is planned by PEP-518 but effective removal of the file was a long-term plan. As a community project, ansible-lint needs to ease contributions from developers, not introducing additional contribution barriers. I am more than willing to help with the additional maintenance needed for keeping the editable mode working. I was told that the original decision was made after an unrecorded discussion made on irc (outside of a meeting). Due to this, I want to reopen the subject and give opportunity to gather feedback from users and developers, especially those that made or wanted to contribute to ansible-lint in the past.