![]() I’ve run my fair share of beta software, but I don’t need every commit as it happens ( cutting vs. But even if I have the inclination and discipline to manage my projects this way, all of my other Emacs packages are getting built from whatever happened to be pushed to master in their own project when the MELPA bot decided to make the rounds. Generally speaking, I keep the master branch on my projects in a functional state, and– yes–I could adopt a development methodology whereby work is always done on a development or feature branch and QA’d before being merged into master. Suddenly I’d become paranoid about exactly what I pushed to the master branch of my project and worried about leaving things in a broken state. I had been installing all of my packages from MELPA, but now, as a fancy-schmancy package author I’d become intensely aware that MELPA builds its packages based on the latest commit in a project’s repository 1. That’s all I have for you today.Writing my first Emacs package a couple months ago left me more cognizant of how Emacs’ packaging system is put together and raised questions about how I use its capabilities. Perhaps the process is easier than I imagine it to Down the road I plan to try to publishĪ few on my own packages to NonGNU ELPA to assess first-hand how much of overhead does it add for package maintainers. ![]() Perhaps we’ll even see some packages move between GNU ELPA and NonGNU ELPA. The primary “standard” package repository. Why limit the number of potential contributors for your projects for no good reason? I expect that over the course of time NonGNU ELPA will become Make much sense for new packages to be added to GNU ELPA, unless they are going to be bundled with Emacs. It seems to me that going forward it doesn’t It’s good have some consistent political views you abide by, but a bit of pragmatism Stable, instead of trying to compete it with I hope that at some pointĮmacs will start enabling by default MELPA I’ll just say that I doubt NonGNU ELPA will gain any meaningful tractionĪnd disrupt the dominance of MELPA in our community. Happening on GitHub/GitLab, but I’m well aware this is never going to As the topic of Emacs and GitHub resurfaces constantly, I won’t reallyĭive in it - I’ve said many times that I’d love to see Emacs’s development ![]() In the end of the day, while I welcome the efforts of Emacs’s team to lower theīar for contributions, I think they are not considering how hard it is toĬompete with the GitHub development flow that most developers are accustomed to ( add-to-list 'package-archives ' ( "nongnu-devel". OSS maintainers are already way too busy and we should valueĪs, with GNU ELPA, there’s also a “devel” version of the NonGNU repository, for unstable releases of the packages hosted on NonGNU ELPA. Not willing to create additional work for myself just to make my work available on NonGNU ELPA. This certainly applies for me - I wouldn’t mind if it was easier for Emacs users to install my packages, but I’m extremely happy with GitHub and MELPA and I’m Mostly on GitHub and the GitHub repo changes are applied afterwards to NonGNU ELPA, but I guess few people are willing to bother with this either. Obviously one can also adopt an approach where the development happens This implies that most people are probably too attached to their GitHub tool chain (and the reach that GitHub has) and are unwilling to move their projects to the "" ))Īs you can see, however, currently the repo boasts a grand total of 5 packages. ( add-to-list 'package-archives ' ( "nongnu". NonGPU ELPA will be enabledīy default in Emacs 28, but for the time being you’ll need to enable it manually like this: One year later the repository is a reality and it’sĪvailable here. The Emacs development team tried to alleviate the situation last year, byĪ default NonGNU ELPA package repository, that eliminates the need for aĬopyright assignment. ![]() Most people are unwilling to deal with copyright assignment hassle and Emacs’s bug In practiceĮvery package that goes into GNU ELPA will likely see few external contributions as Popular with developers today, few people are willing to forgo it. With MELPA there are no copyright assignments (and byĪssociations - no contribution limitations) and you don’t need to host your The answer is quite obvious - the amount of work a package maintainer needs toĭo in both cases. Where’s the huge difference of scale between ELPA and MELPA coming from? To me, In GNU ELPA are bundled with Emacs (meaning they originated from people involved A respectable number, but quiteįar from the 5000 packages available in the popular community-maintained ![]() Of this writing it hosts around 280 packages. Ever since package.el became the standard package manager for Emacs, there hasīeen an official Emacs package repository called GNU ELPA. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |