Python

I found out the hard way that SaltStack and Debian no longer place nice together. I had upgraded a Debian installation from Bullseye to Bookworm, along with the resident Salt Minion. When attempting to use the minion, it no longer starts up, due to various imports no longer working. Which was due to the salt-minion not being upgraded. The error message would started this odyssey:

salt ImportError: cannot import name 'Markup' from 'jinja2'

Taking a look at the Debian Developer Information for Salt, the last version started in 'unstable' was 3004.1 back in December of 2022. This is now almost 8 months later and little or no movement. There was some mention in a ticket somewhere that Salt release cycles don't cater to Debian stable release cycles. Not sure if that is a legitimate reason or not, but, well, for whatever reason, SaltStack management in Debian is no longer a simple no brainer.

However, after a little digging, there is a way to run SaltStack versions 3006 (current as of this writing). It is simple to install on Bullseye, but not easily done on Bookworm.

On Bullseye (as root, or implies sudo):

# cd ~ # apt remove salt-minion salt-master # apt install curl # curl -L https://bootstrap.saltstack.com -o install_salt.sh # sh install_salt.sh -M onedir

The '-M' installs the salt master at the same time (for machines running master). If you forget to do that, you'll need to diagnose and fix the systemctl mask error with the following:

# apt install file # file /etc/systemd/system/salt-master.service # rm /etc/systemd/system/salt-master.service # systemctl daemon-reload # sh install_salt.sh -M onedir

The 'sh install_salt.sh -M onedir' should show a symlink to /dev/nul, which the 'rm ...' will fix.

On Bookworm, the bootstrap isn't scheduled to work till beginning of 2024 sometime I think with Salt 3007 or 3008 -- more info in [FEATURE REQUEST] Add Salt support for Debian 12 #64223 .

In the meantime, I had to cheat a bit:

• in /etc/debian_version, change 12.0 to 11.0
• in /etc/apt/sources.list, change bookworm to bullseye
• rm /etc/apt/sources.list.d/salt.list
• run apt update
• run the commands listed above for installing the one or both the salt services
• restore /etc/debian_version and /etc/apt/sources.list to their original content

I'm sure there are more elegant ways of doing this, but this worked to fake the needed version 11 in the installation script and directory traversal requirements

Note, more info on the Salt Install/Bootstrap Process.

My browser is getting littered with Django references. Time to collect them together:

• Simple Django Web Application Tutorial
• Getting started with Generic Class Based Views in Django
• Ask HN: Best resources to learn django in 2017?

Routing

• pyroute2
• NetworkX

Mininet

• Ehsan70 RyuApps

Ryu

• osrg/ryu on github
• SDN Lab topology discovery with Ryu
• Ryu ReadTheDocs
• Ryu Book
• Sample Code

Web applications

• clean simple cms: said by some to be all the rage
• Tornado is a Python web framework and asynchronous networking library
• django cms
• RevSys talks Wagtail
• Celery: Distributed Task Queue
• Mezzanine: content management platform built using the django framework quota: Mezzanine vs django

• Flask vs Django

There appears to be any number of Integrated Development Environments, and here for Python. I needed to select one for my own development.

I've been using NetBeans for my C++ development cycles, and therefore wanted to use the same environment for Python. No such luck. Support for a Python add-in has been discontinued. Not sure why.

There were lots of good comments for the commercially supported environments, but I ended up looking for something in the 'free' range. A quick review showed that Eclipse supports a Python add-in called PyDev. I installed it without the LiClipse bundle. After giving Eclipse/PyDev a try for a few days, it appears to handle the job quite nicely.

My only issue at the moment is that the IDE doesn't seem to be able to load all necessary libraries and parse them properly for error free syntax checking. Even though the modules appear to build and run properly. Perhaps I have not properly configured the environment. The one special thing that I've done is create a custom run configuration in order to make use of the virtualenv environment for each of my projects.

easter egg: python -c "import this"

pypy offers code speed up

pickle: simple object persistence

pillow: image processing

pyro: distributed processing

Unix env Lookup Trick: on some systems, the path to the python interpreter can be indirected via the environment variable (Learning Python 5e, page 60)

#!/usr/bin/env python
........

Python has two separate common versions happening: 2.7 and 3.somethingorother. There are language differences between the two. And since both versions are active, both versions have to be supported, and the libraries for each, due to language differences between versions, have to be managed separately.

To do this, something called virtualenv was created. The short form of getting things functioning:

[sudo] pip install virtualenv  # installs the package
mkdir       # create a directory for the project
cd          # get settled into the directory
virtualenv env       # creates a project local environment for libraries (first part of the the magic trick)
. env/bin/activate   # use each time when starting project work (second part of magic trick, fixing path)
deactivate   # use when ready to undo the path fix

When researching the Augmented Dickey Fuller test, I came across two books that would be good for programmers. They use Python as a reference language, but hey, at least they take the programmer's point of view. Converting to C++ as needed shouldn't be too difficult. 'Think Stats', which is coming out in Edition 2, and 'Think Bayes', which builds on the 'Think Stats' book.