Posts
Snippet Pixie: Next - Always Developing #60
Today I published Always Developing session #60, which is both the start of a new series of videos, and a new chapter for my Snippet Pixie application.
Snippet Pixie: Next - Rebuilding from scratch with Go | Always Developing #60
Snippet Pixie: Next
As the video title suggests, I'm rebuilding Snippet Pixie from the ground up using a completely different programming language. Instead of Vala, I'm going to use Go for the rewrite.
Reasons For Rewrite
There's a number of reasons that I'm doing this, but first and foremost it's because I'm wanting to learn the Go programming language.
A good chunk of my earlier Always Developing sessions were with me building a GoalMonitor web application to help me learn Go for the back end, and Svelte for the front end.
Playlist: GoalMonitor - Svelte + Go + CockroachDB + Juju
I've recorded 40 GoalMonitor related sessions, but found myself not wanting to continue with them, leading to skipping recording (making a lie of "Always Developing"), or making videos on different subjects instead. The application was starting to get to the point where I'd need to invest considerable time into completing it, but it's not a project I currently need. Without that need for the application, I just don't have enough motivation to push it forward in my spare time, even though I would likely learn a huge amount by doing so.
Snippet Pixie is a project that I'm passionate about, that I use many many times every day, but yet is in need of some attention to address some issues it currently has, and push it forward. Some of the issues with Snippet Pixie that I need to address relate to it's current architecture, and there's quite of lot of work needed to fix that. I'd rather spend that time working with Go than Vala. Go is rather good for building daemon and CLI apps, which just so happens to be part of my plan for improving Snippet Pixie's architecture and unblock the path to fixing some of its issues.
Don't get me wrong, Vala is a perfectly fine language, in fact I quite like it, but even with as little experience as I have in either Go or Vala, I'm drawn more to Go.
While wanting to learn Go and needing to fix the code bases' architecture are the main reasons for re-coding Snippet Pixie from scratch, it also gives me the opportunity to use a different license.
New License
Snippet Pixie currently uses the GNU General Public License v2.0 (GPLv2) license.
https://github.com/bytepixie/snippetpixie/blob/develop/LICENSE
I don't like the GPLv2 license because it imposes too many conditions that restrict your freedom to use the code as you see fit. I would much prefer that if someone finds useful code in Snippet Pixie's code base they can use it without worrying about the implications of doing so.
As such, I'm using the MIT license for the new from scratch Snippet Pixie code base.
https://choosealicense.com/licenses/mit/
This may turn out to be particularly helpful if I end up creating any Go packages that can be used by others. As the development of Snippet Pixie progresses there's a good chance I'll end up working with the AT-SPI2 DBUS interface if wanting to keep feature parity with the current release of Snippet Pixie.
https://gitlab.gnome.org/GNOME/at-spi2-core/
That interface is currently used by Snippet Pixie to implement auto-expansion of snippets. Unfortunately I've not been able to find any currently maintained Go libraries for dealing with the AT-SPI2 service, so I may end up having to work on that myself. That's a long way off though, and frankly may never happen as I find myself using Snippet Pixie's "Search & Paste" window way more than auto-expansion. Search & Paste has far better compatibility across applications as many don't implement the required accessibility features, and I often find it easier to type a few letters into the search dialogue than try and remember the abbreviation I set for a particular snippet.
Contributions
Apart from myself, there have been 4 other lovely people that have been generous enough to contribute to Snippet Pixie.
https://github.com/bytepixie/snippetpixie/graphs/contributors
Ordinarily I believe this might cause a problem with re-licensing as you should get everybody's approval for the parts they've contributed to as they hold the copyright, or something to that effect (I'm not a lawyer, have never played one on TV, and have zero interest in becoming a lawyer). However, 2 of those contributors only touched files related to building the .deb package or running tests on Travis CI, neither of which need to be carried forward to the new version of Snippet Pixie. Their contributions were super helpful, but going forward I don't need to worry about their copyright for the code they contributed.
The other 2 contributors mostly touched the translation files, and little bit of the build config related to translation, and I think made a string or two translatable in the core codebase.
I would rather not lose the work done on those translations, it's incredibly valuable work, but I'm unclear as to whether I would be able to update the license in the current repo without some sort of official gubbins. I'm sure NathanBnm and Vistaus would give their blessing, but I'm not sure whether there's anything (or anyone) else that I need to take into consideration before switching out the license.
New Code Repository
As I'm not the sole contributor to the current version of Snippet Pixie but want to use a different license, I've gone the safe route and started again from a new repository.
What I might do in the future is take the translation data and massage it into a new format that I anticipate needing to generate for the new Go code base. Once generated (or most likely painstakingly copy/pasted one line at a time) I'll seek out NathanBnm and Vistaus to get their blessing before merging into the main branch.
In the video I mention that another reason for the new repository is that as I'm trying to learn Go as part of this rewrite, I'd rather not have any outside contributions at the moment. I don't want some kind sole contributing a bunch of excellent code that means I don't get to learn how to implement that feature or whatnot myself, or that I may not fully understand yet anyway! I'm all for comments on my videos letting me know about a trick I've missed or some doc I should take a gander at though.
So I've created a brand new GitHub organisation for Snippet Pixie, and as part of the video linked above you can see that I created a private repo. In due course it'll be made public.
Finally, another reason for using a new repo is that the current Snippet Pixie repo has a few services hooked up for testing and package building that I'd rather not disrupt. If I were to start committing to the old repo those services would be triggered, I don't want that, and don't want to go through the hassle of trying to filter the service's triggers. The current version of Snippet Pixie may need a bug fix or two while I'm progressing with the rewrite, so I'd prefer to keep its repo in full working order.
Going Forward
So that's me now set up with plenty of work to do as part of my (almost) daily Always Developing sessions. I'm really looking forward to getting stuck into developing with Go again, and who knows what other technologies get thrown into the mix as I rebuild Snippet Pixie and its adjacent projects.
If you want to follow along, don't forget to subscribe to my YouTube channel!
Thanks for reading, until next time, take care!
---
"Snippet Pixie: Next - Always Developing #60" was published on September 29, 2021.