170 lines
14 KiB
XML
170 lines
14 KiB
XML
<?xml version="1.0" encoding="UTF-8"?>
|
|
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
|
|
<channel>
|
|
<title>Glenn Thompson's Blog</title>
|
|
<description>Personal blog about programming, technology, and other interests</description>
|
|
<link>https://glenneth.org</link>
|
|
<atom:link href="https://glenneth.org/feed.xml" rel="self" type="application/rss+xml" />
|
|
<language>en-us</language>
|
|
<lastBuildDate>Sun, 28 Sep 2025 08:21:15 GMT</lastBuildDate>
|
|
|
|
<item>
|
|
<title>Development Environment Evolution: Embracing Guix Home and Enhanced Emacs Workflow</title>
|
|
<description>"Six months after my comprehensive development environment overview, I share the significant evolution to Guix Home and enhanced Emacs configurations that have transformed my daily workflow."</description>
|
|
<content:encoded><![CDATA[<h2>Introduction</h2>
|
|
<p>Six months ago, I shared a detailed look at my <a href="/content/posts/2025-03-08-my-dev-environment-2025.html">development environment in 2025</a>, covering my hybrid approach with ArcoLinux, Guix package management, and Emacs-centered workflow. Since then, my setup has undergone a significant evolution driven by both choice and necessity.</p>
|
|
<p>The most significant change has been a transition to <strong>WSL2 on Windows 11</strong> for my work environment, necessitated by corporate requirements. Rather than seeing this as a limitation, I've embraced it as an opportunity to refine my development approach, adopting <strong>Guix Home</strong> for complete environment management and building a custom Emacs installation from the master branch.</p>
|
|
<p>This evolution has taught me valuable lessons about adaptability and the power of declarative configuration in maintaining consistency across different underlying systems.</p>
|
|
<h2>The Guix Home Revolution</h2>
|
|
<h3>From Hybrid to Unified</h3>
|
|
<p>In March, I described my hybrid approach using both pacman/AUR and Guix for different aspects of my system. While this worked well, I found myself constantly managing the boundary between system and user packages, dealing with occasional conflicts, and maintaining separate configuration files.</p>
|
|
<p><strong>Guix Home</strong> changed everything. Now I can declaratively manage:</p>
|
|
<ul>
|
|
<li>All my development tools and applications</li>
|
|
<li>Shell configuration and environment variables </li>
|
|
<li>Dotfiles and configuration files</li>
|
|
<li>Services and background processes</li>
|
|
<li>Desktop environment customizations</li>
|
|
</ul>
|
|
<h3>Current Guix Home Configuration</h3>
|
|
<p>My <code>home-configuration.scm</code> has become the single source of truth for my development environment, particularly focused on Scheme/Guile development:</p>
|
|
<pre><code class="language-scheme">;; Guix Home configuration for Glenn's Scheme development environment
|
|
|
|
(use-modules (gnu home)
|
|
(gnu packages)
|
|
(gnu services)
|
|
(gnu home services)
|
|
(gnu home services shells)
|
|
(gnu home services guix)
|
|
(gnu home services mcron)
|
|
(guix gexp))
|
|
|
|
(home-environment
|
|
;; Packages to install in the home environment
|
|
(packages (specifications->packages
|
|
'(;; System essentials
|
|
"glibc-locales"
|
|
|
|
;; Scheme/Guile development environment
|
|
"guile-next" ; Latest Guile development version
|
|
"guile-hoot" ; Scheme to WebAssembly compiler
|
|
"guile-goblins" ; Distributed programming environment
|
|
"guile-lib" ; Useful Guile libraries
|
|
"guile-reader" ; Reader extensions for Guile
|
|
"guile-json" ; JSON support for Guile
|
|
|
|
;; Development tools
|
|
;; Note: Using custom-built Emacs 31.0.50 installation
|
|
"git" ; Version control
|
|
"make" ; Build system
|
|
"gcc-toolchain" ; C compiler and tools
|
|
"pkg-config" ; Package configuration
|
|
"texinfo" ; Documentation system
|
|
"rlwrap"))) ; Readline wrapper for better REPL experience
|
|
|
|
;; Services for the home environment
|
|
(services
|
|
(list
|
|
;; Set up environment variables for Scheme development
|
|
(simple-service 'scheme-dev-env-vars
|
|
home-environment-variables-service-type
|
|
'(("EDITOR" . "emacs")
|
|
("GUILE_LOAD_PATH" . "$HOME/.guix-home/profile/share/guile/site/3.0:$GUILE_LOAD_PATH")
|
|
("GUILE_LOAD_COMPILED_PATH" . "$HOME/.guix-home/profile/lib/guile/3.0/site-ccache:$GUILE_LOAD_COMPILED_PATH")
|
|
("GUIX_LOCPATH" . "$HOME/.guix-home/profile/lib/locale")
|
|
("GUILE_AUTO_COMPILE" . "1")
|
|
("GUILE_WARN_DEPRECATED" . "detailed")))
|
|
|
|
;; Add a simple mcron job for keeping system updated
|
|
(simple-service 'update-reminder
|
|
home-mcron-service-type
|
|
(list #~(job "0 12 * * 0" ; Every Sunday at noon
|
|
"echo 'Consider running: guix pull && guix home reconfigure ~/.config/guix/home-configuration.scm'"))))))
|
|
</code></pre>
|
|
<h3>Benefits Realized</h3>
|
|
<p>The transition to Guix Home has delivered on its promises:</p>
|
|
<p><strong>Complete Reproducibility</strong>: I can now recreate my entire user environment on any machine with a single command: <code>guix home reconfigure home-configuration.scm</code></p>
|
|
<p><strong>Atomic Updates</strong>: Changes to my environment are atomic - either they work completely or roll back cleanly. No more broken states from partial updates.</p>
|
|
<p><strong>Version Control Everything</strong>: My entire environment configuration lives in Git, with meaningful commit messages tracking every change to my setup.</p>
|
|
<p><strong>Effortless Rollbacks</strong>: When an update breaks something, <code>guix home roll-back</code> instantly restores the previous working state.</p>
|
|
<p><strong>Dependency Isolation</strong>: Each application gets exactly the dependencies it needs, eliminating conflicts between different tools requiring different library versions.</p>
|
|
<h2>Enhanced Emacs Workflow</h2>
|
|
<h3>Custom Emacs Build from Master</h3>
|
|
<p>One of the most significant changes in my setup has been building Emacs from the master branch rather than relying on distribution packages. This decision was driven by several factors:</p>
|
|
<ul>
|
|
<li><strong>Latest Features</strong>: Access to cutting-edge features and improvements before they reach stable releases</li>
|
|
<li><strong>WSL2 Optimization</strong>: Better integration with the WSL2 environment through custom compilation flags</li>
|
|
<li><strong>Performance Tuning</strong>: Ability to optimize the build for my specific use case and hardware</li>
|
|
</ul>
|
|
<p>Building Emacs 31.0.50 from source on WSL2 Ubuntu has given me a more responsive and feature-rich editing environment, particularly for Scheme development where the latest improvements in language support make a noticeable difference.</p>
|
|
<h3>Configuration Management Evolution</h3>
|
|
<p>While I was already using Emacs extensively in March, my configuration approach has matured significantly. I've moved from a monolithic configuration to a modular, feature-based system that's easier to maintain and debug.</p>
|
|
<h3>New Emacs Enhancements</h3>
|
|
<p><strong>Improved LSP Integration</strong>: My language server setup now provides more consistent and reliable code intelligence across all my projects.</p>
|
|
<p><strong>Enhanced Org Mode Workflow</strong>: I've integrated Org mode more deeply into my daily workflow for:</p>
|
|
<ul>
|
|
<li>Project planning and tracking</li>
|
|
<li>Meeting notes and documentation</li>
|
|
<li>Time tracking and productivity analysis</li>
|
|
<li>Knowledge management and linking</li>
|
|
</ul>
|
|
<p><strong>Better Terminal Integration</strong>: Using <code>vterm</code> and <code>multi-vterm</code>, I now have seamless terminal integration within Emacs, reducing context switching.</p>
|
|
<p><strong>Refined Completion System</strong>: My completion setup with Vertico, Consult, and Marginalia has been fine-tuned for faster, more intuitive navigation.</p>
|
|
<h3>Development Workflow Improvements</h3>
|
|
<p><strong>Project Management</strong>: Using <code>projectile</code> with enhanced project templates and automated setup scripts.</p>
|
|
<p><strong>Code Quality</strong>: Integrated formatting, linting, and testing directly into my editing workflow with immediate feedback.</p>
|
|
<p><strong>Documentation</strong>: Streamlined documentation generation and maintenance using Org mode's export capabilities.</p>
|
|
<h2>Workflow Integration Benefits</h2>
|
|
<h3>Seamless Environment Switching</h3>
|
|
<p>With Guix Home managing my entire environment, switching between different project contexts has become effortless. Each project can specify its exact dependencies, and Guix ensures they're available without affecting other projects.</p>
|
|
<h3>Consistent Across Machines</h3>
|
|
<p>Whether I'm working on my desktop, laptop, or a remote server, my environment is identical. This consistency has eliminated the "works on my machine" problem entirely.</p>
|
|
<h3>Simplified Onboarding</h3>
|
|
<p>Setting up a new development machine now takes minutes instead of hours. Clone my configuration repository, run <code>guix home reconfigure</code>, and everything is ready.</p>
|
|
<h2>Challenges and Solutions</h2>
|
|
<h3>Learning Curve</h3>
|
|
<p><strong>Challenge</strong>: Guix Home's declarative approach required rethinking how I manage my environment.</p>
|
|
<p><strong>Solution</strong>: Incremental migration, starting with simple configurations and gradually adding complexity as I became more comfortable with the system.</p>
|
|
<h3>Documentation Gaps</h3>
|
|
<p><strong>Challenge</strong>: Guix Home is relatively new, with fewer examples and tutorials compared to traditional dotfile management.</p>
|
|
<p><strong>Solution</strong>: Active participation in the Guix community, reading source code, and documenting my own discoveries.</p>
|
|
<h3>Integration Complexity</h3>
|
|
<p><strong>Challenge</strong>: Some applications required custom integration work to play nicely with Guix Home.</p>
|
|
<p><strong>Solution</strong>: Creating custom service definitions and contributing them back to the community when possible.</p>
|
|
<h2>Performance and Productivity Impact</h2>
|
|
<p>The move to Guix Home has had measurable impacts on my productivity:</p>
|
|
<ul>
|
|
<li><strong>Reduced Setup Time</strong>: New project environments spin up in seconds</li>
|
|
<li><strong>Fewer Context Switches</strong>: Everything I need is consistently available</li>
|
|
<li><strong>Less Debugging</strong>: Reproducible environments mean fewer environment-related issues</li>
|
|
<li><strong>Improved Focus</strong>: Less time managing tools means more time creating</li>
|
|
</ul>
|
|
<h2>Future Directions</h2>
|
|
<p>Looking ahead, I'm exploring:</p>
|
|
<p><strong>Custom Guix Channels</strong>: Creating personal channels for specialized tools and configurations not yet in the main Guix repository.</p>
|
|
<p><strong>Advanced Service Integration</strong>: Developing more sophisticated service definitions for complex development workflows.</p>
|
|
<p><strong>Cross-Machine Synchronization</strong>: Using Guix Home with remote development servers and cloud environments.</p>
|
|
<p><strong>Community Contributions</strong>: Sharing useful service definitions and configurations with the broader Guix community.</p>
|
|
<h2>Lessons Learned</h2>
|
|
<h3>Embrace Gradual Migration</h3>
|
|
<p>Don't try to convert everything at once. Start with core tools and gradually expand your Guix Home configuration as you become more comfortable with the system.</p>
|
|
<h3>Document Everything</h3>
|
|
<p>Keep detailed notes about your configuration choices. The declarative nature of Guix Home makes it easy to forget why you made certain decisions.</p>
|
|
<h3>Engage with the Community</h3>
|
|
<p>The Guix community is incredibly helpful and knowledgeable. Don't hesitate to ask questions and share your experiences.</p>
|
|
<h3>Version Control is Essential</h3>
|
|
<p>Treat your Guix Home configuration like any other important code - use meaningful commit messages, create branches for experiments, and maintain good version control hygiene.</p>
|
|
<h2>Conclusion</h2>
|
|
<p>The evolution from my March setup to the current Guix Home-based environment represents more than just a tool change - it's a fundamental shift in how I think about development environment management. The move from imperative to declarative configuration has brought a level of reliability and reproducibility that has transformed my daily workflow.</p>
|
|
<p>For anyone considering similar changes, I'd recommend starting small and gradually expanding your declarative configuration. The initial learning curve is worth the long-term benefits of having a truly reproducible, version-controlled development environment.</p>
|
|
<p>The combination of Guix Home for environment management and a refined Emacs configuration has created a development setup that feels both powerful and effortless. It's a foundation I'm confident will serve me well as my projects and requirements continue to evolve.</p>
|
|
<p>What aspects of environment management do you find most challenging? Have you experimented with declarative configuration approaches? I'd love to hear about your experiences and any questions you might have about making similar transitions.</p>
|
|
]]></content:encoded>
|
|
<link>https://glenneth.org/content/posts/2025-09-28-dev-environment-evolution-guix-home.html</link>
|
|
<guid isPermaLink="true">https://glenneth.org/content/posts/2025-09-28-dev-environment-evolution-guix-home.html</guid>
|
|
<pubDate>Invalid Date</pubDate>
|
|
<author>Glenn Thompson</author>
|
|
<category>["development", "guix", "guix-home", "emacs", "workflow", "productivity", "evolution"]</category>
|
|
</item>
|
|
</channel>
|
|
</rss> |