2020-05-29T00:52:38.632878+00:00 Albert Wang python-feedgen Python Release Support Timesline 2019-12-26T23:38:46-08:00 Albert Wang <p>Since I&#8217;ve had a hard time determining when versions of Python are pre-release, supported, or deprecated, here&#8217;s a table of all recent python versions:</p> <table> <thead> <tr> <th>Version</th> <th>Release</th> <th>End of security fixes</th> </tr> </thead> <tbody> <tr> <td>2.7</td> <td>2010-07</td> <td>2020-01</td> </tr> <tr> <td>3.4</td> <td>2014-03</td> <td>2019-03</td> </tr> <tr> <td>3.5</td> <td>2015-09</td> <td>2020-09</td> </tr> <tr> <td>3.6</td> <td>2016-12</td> <td>2021-12</td> </tr> <tr> <td>3.7</td> <td>2018-06</td> <td>2023-06</td> </tr> <tr> <td>3.8</td> <td>2019-10</td> <td>2024-10</td> </tr> <tr> <td>3.9</td> <td>2020-10</td> <td>2025-10</td> </tr> </tbody> </table> Sendmail Wrapper for Mailgun 2020-03-01T18:05:00-08:00 Albert Wang <p>If you use the <code>sendmail</code> linux CLI and you want to route outgoing emails through mailgun, write this file, make it executable, and add it to your path before the actual exectuable is found:</p> <div class="codehilite"><pre><span></span><code><span class="ch">#!/bin/bash</span> <span class="c1"># Shim for netdata to send emails through mailgun</span> <span class="c1"># filename: sendmail</span> <span class="c1"># suggested location: /usr/local/bin/</span> <span class="c1"># Installation:</span> <span class="c1"># 1. Write the contents of this script to a file called &quot;sendmail&quot;</span> <span class="c1"># 2. Fill in the mailgun smtp email and password from</span> <span class="c1"># 3. sed -i &#39;s/SENDMAIL_PATH_REPLACE_ME/$(mailgun)/g&#39; sendmail</span> <span class="c1"># 4. `chmod +x sendmail`</span> <span class="c1"># 5. `sudo mv -n sendmail /usr/local/bin`</span> <span class="nv">SENDMAIL_PATH</span><span class="o">=</span><span class="s2">&quot;SENDMAIL_PATH_REPLACE_ME&quot;</span> <span class="nv">MAILGUN_EMAIL</span><span class="o">=</span><span class="s2">&quot;REPLACE_ME&quot;</span> <span class="nv">MAILGUN_PASSWORD</span><span class="o">=</span><span class="s2">&quot;REPLACE_ME&quot;</span> <span class="c1"># shellcheck disable=SC2068</span> <span class="s2">&quot;</span><span class="nv">$SENDMAIL_PATH</span><span class="s2">&quot;</span> <span class="se">\</span> -S <span class="se">\</span> -au <span class="s2">&quot;</span><span class="nv">$MAILGUN_EMAIL</span><span class="s2">&quot;</span> <span class="se">\</span> -ap <span class="s2">&quot;</span><span class="nv">$MAILGUN_PASSWORD</span><span class="s2">&quot;</span> <span class="se">\</span> <span class="nv">$@</span> </code></pre></div> Quote 2020-03-05T00:58:51-08:00 Albert Wang <p>Shamelessly stealing off of <a href="">Hacker News</a></p> <p><img src="/static/notes/20200305-0858.jpg" alt="Microservices are a design philosophy that people confuse as a deployment strategy" /></p> Developing Django in Production 2020-05-15T00:38:19-07:00 Albert Wang <p>Django is still my favorite web framework. While it comes with a neat system for rolling forward and back relational database schema migrations, you still have to populate your test and local databases with fixture data. Instead, you can use this script (configuration required) to connect your local django app to production to help test your code against production data:</p> <div class="codehilite"><pre><span></span><code><span class="ch">#!/bin/bash</span> <span class="c1"># Connect your local django app to a production database</span> <span class="nb">set</span> -ex <span class="nv">LOCAL_IP</span><span class="o">=</span><span class="m">127</span>.0.0.1 <span class="c1"># The local port that you want to use to forward to your production database</span> <span class="c1"># This is set to the mysql default port, incremented by 1 so that it doesn&#39;t conflict with your local database</span> <span class="nv">LOCAL_PORT</span><span class="o">=</span><span class="m">3307</span> <span class="c1"># The remote host (or IP) that can access your production database</span> <span class="c1"># This is probably where your app is hosted</span> <span class="nv">REMOTE_HOST</span><span class="o">=</span> <span class="c1"># The ip that your production app uses to connect to your production database</span> <span class="nv">REMOTE_IP</span><span class="o">=</span><span class="m">172</span>.24.0.3 <span class="c1"># The port that your production app uses to connect to your production database</span> <span class="nv">REMOTE_PORT</span><span class="o">=</span><span class="m">3306</span> <span class="c1"># Create an ssh tunnel from localhost to production</span> ssh -fNL <span class="nv">$LOCAL_IP</span>:<span class="nv">$LOCAL_PORT</span>:<span class="nv">$REMOTE_IP</span>:<span class="nv">$REMOTE_PORT</span> <span class="nv">$REMOTE_HOST</span> <span class="c1"># Reset everything when this script is killed</span> <span class="k">function</span> cleanupSSH <span class="o">{</span> pkill -f <span class="s2">&quot;</span><span class="nv">$REMOTE_IP</span><span class="s2">&quot;</span> rm .env ln -s .env.development .env <span class="o">}</span> <span class="nb">trap</span> cleanupSSH EXIT <span class="c1"># Assuming you keep configs in .env, switch the symlink to a prodlocal config</span> <span class="c1"># This is likely a mixture of development and production configs</span> rm .env ln -s .env.prodlocal .env <span class="c1"># Start up django</span> ./ runserver </code></pre></div> Upgrading LibMySQLClient in Python MySQLDB/MySQLClient 2020-05-25T19:55:28-07:00 Albert Wang <p>After upgrading from Ubuntu 18.04 to Ubuntu 20.04, I ran into this error when trying to import python&#8217;s <code>mysqlclient</code>:</p> <pre><code>ImportError: cannot open shared object file: No such file or directory </code></pre> <p>After spending a while debugging it, I found the python <code>mysqlclient</code> package is a fork of <code>MySQLdb</code> which compiles a <code>_mysql.*.so</code> file which references <code>*</code>. However, <code></code> gets updated every so often (with the most recent update from <code>20</code> to <code>21</code>) which makes <code>mysqlclient</code> lose track of the <code></code> version when installed with pip. After trying various ways of clearing build caches, I was able to find a workaround by:</p> <ol> <li>Ensuring <code>libmysqlclient</code> is installed (<code>sudo apt install libmysqlclient-dev</code>)</li> <li>Cloning the <a href="">mysqlclient</a> from github (<code>git clone</code>)</li> <li>Manually building mysqlclient (<code>make build</code>)</li> <li>Copying the generated <code>_mysql.*.so</code> to my virtualenv</li> </ol> <p>I&#8217;m still trying to find a better way of doing this so I can get a working <code>mysqlclient</code> after running <code>pip install mysqlclient</code>.</p>