In July I deployed a major update to dpaste.com. Nothing exploded. Good things resulted.
It looks different of course, but here’s the other stuff that’s new:
- Proper user accounts replaced the old cookie-based “accounts”
- Signup via GitHub, GitLab, Bitbucket, Google, or plain ol’ username/password
- “Favorites” feature
- Optional public profile (linked from items you post)
- Responsive HTML layouts (looks good on your phone now!)
- 100% HTTPS
- More robust database setup
- Application hosting by PythonAnywhere
- Lengthened the base-32 item IDs from 7 to 9 digits (and dropped the ambiguous
- Added a latest-item blurb (with geolocation when available) to the About page, for fun. E.g. “3.6 KB of Python console session from a registered user in Москва, Россия”
- Switched from Twitter to Mastodon for the status feed.
Project hosting: Sourcehut
I also moved my project hosting from Bitbucket to Sourcehut.
This is a bit of a sidebar because it’s about more than the dpaste project. It was about Mercurial support. When Bitbucket announced last year that they were dropping Mercurial (which I’m quite fond of), I started hunting for a new home for all my Mercurial repos.
Options I considered (and ultimately rejected) were:
- “Just” converting everything to Git. I did this for some legacy repos, but I enjoy using Mercurial a lot (and am uneasy about technical monocultures)
- Sourceforge. Not Dead Yet, and supports Mercurial. However, some of my repos are private but SF is open-source only.
- Self-hosting. Fun in theory, but I don’t want the system administration burden.
- Helix TeamHub by Perforce. This one almost won. Supports Mercurial, and private repos, and has all the features. Unfortunately it just didn’t click; it felt overbuilt and soulless.
In the end I chose Sourcehut because it provides the services I need (private Mercurial repos, issue tracker, etc.) and is an open source project. I hit one error in the system early on, and the response (an email notifying me the fix had been deployed, with a link to the patch) was gratifying.
I signed up for a paid account.
Application hosting: PythonAnywhere
Another milestone: I’m no longer self-hosting. For many years I’ve used a FreeBSD VPS for hosting all my projects. One by one I’ve been porting them to more suitable lower-maintentance platforms (this blog, for instance, is now served from Azure static storage).
After surveying the current Python-web-app hosting options, I chose PythonAnywhere. It provides the pieces I need to deploy my production Python web app, but doesn’t make me manage them like a sysadmin.
I can still SSH to the server to run management commands or do hot fixes, but I don’t have to think much about the platform itself.
Having previously been the target of a DDoS attack, I did initially balk at giving up access to the web server configuration (for more efficient blocking than you can do in the application layer), but that’s one of the only things I’ve pined for.
I traded the freedom (and burden) of running and maintaining everything myself, for the ability to focus only on building the application. That’s been great.
The update has made it easier (and more fun) to work my way down the to-do list. Features in the queue include API auth, syntax-coloring improvements, and syntax-guesser improvements. Watch the status feed for news.