straight.el as a classic example of overengineering in emacs?

I am really impressed of the project page, complex documentation, but seriously what problem is solved by using this package? I don't know any notable users who share own init.el and theirs configuration is based on straight. Am I wrong?

Every single Doom Emacs user is using straight.el, for example. From my POV it is an excellent complement to `use-package` in general - not just for "framework" or "distribution" users. Being able to freeze your config packages (and version that lockfile in git) for reproducible environments over time or between machines is excellent.

Ability to easily use packages from git repositories or your own forks (without hassle of manually managing files or git submodules) is something that I really appreciate for example.

[deleted]

Used straight for ages. It's a no brainer for me as you can wrap it in straight's use-package syntax, so it's always compatible

> seriously, what problem is solved by using this package? The documentation now sounds less impressive than you originally made it sound. > I don't know any notable users who share own init.el and theirs configuration is based on straight. Is the number of users somehow relevant? (Notwithstanding that I see people talking about this package very frequently.)

Quite the contrary, I would say. The code is not as long as the documentation would make you believe. With straight.el, only the packages you have explicitly said should be used with `straight-use-package` are active. This frees you up to not have to deal with the big messy stateful thing that is package.el, which is a huge boon. I think the real question is why package.el is >4000 lines of code.

You are right in that some aspects of the package (the bootstrapping process, generalization of the vc backend, some of the functions) are over engineered. The documentation needs a rewrite as well. Ideally it would be much more to the point and much of the information it has could be moved to smaller, separate pages. You are wrong in that the package is incredibly useful and has some fantastic ideas in it. It's impressive that the original author conceived of and executed the package as well as they did while still in school. Its age is showing a bit now, but it holds up remarkably well and is the package manager for many users (some of which aren't even aware they're using it). I currently maintain straight.el, but I am also in the process of writing a new package manager which is simpler in design and solves some of the outstanding issues with straight. Some of the ideas in it are directly inspired by straight, though.

I think the documentation is actually a bit weak for straight (and use-package) because it's a little hard to summarize and organize. Same with other complex packages like Hyperbole. Package management in Emacs is sometimes a headache. I have my config checked in to git and would love to be able to simply git clone the config anywhere and have emacs behave the same way. Some of the complication to that is normal stuff like setting up environment variables correctly. Some of that is depending on external systems like language servers or LaTeX parsers. But a major barrier to that is getting packages and their versions right. Emacs doesn't come with something like a requirements.txt or a maven or gradle or sbt or what have you. There's no default way to specify a list of packages you'd like to install, the source from which you'd like to install them and a version. MELPA stable seems like it should help with this, but in practice, it doesn't. Straight allows you to create a reproducible set of packages. This does a lot for me in terms of limiting the number of times some package breaks things (or just disrupts a workflow that I am accustomed to.) Because most people who use straight also use use-package, you won't *see* straight in the config, apart from initializing it in the early\_init. But it is used by a large number of people. Some of the older crowd have, by necessity, solved this problem on their own and as such don't need to refactor their entire config to accommodate straight (or use-package). So that's why you might not see in in the configs of the old-guard power users. But I did that config refactor, out of curiosity, and I'm happy with the results.

IMO the main advantages of straight are 1. You can install small packages that haven’t been released on (m)epla by simply referencing the git repo. This is great for new packages that having picked up steam yet. 2. You can specify which branch of a project to install, which is great for testing experimental features 3. It’s great for anyone contributing to a package because to can specify both your fork and the upstream repo in your recipe. All these are really for people who are actively developing for emacs or trying to really be on the bleeding edge—probably not really useful for a person who’s simply trying to use emacs to edit some text with minimal addons. Not for everyone, but there is definitely a user based.

Even if you're just using a few *personal* packages, if you keep them in git, straight is super helpful. I much prefer that to adding a local file to the load path. It's much less brittle and easy to roll-back.

> Ability to easily use packages from git repositories Quelpa has been there for a while, though

As others have pointed out, Doom uses straight.el and there are some pretty notable Doom-based configurations around, for instance, [tecosaurs's](https://github.com/tecosaur/emacs-config).

Besides what's already been mentioned, straight is very useful if you want to share your configuration between machines.

Another drop in the bucket here. As a newer emacs user (<1 year) coming from the vim plugin ecosystem I really like the packages being git repos. In fact, it's almost indispensable for me (I can roll my own extension for personal use and put it in a separate repo, then pull it with straight instead of having to publish to melpa or keep it as part of my dotfiles). Sure, straight may well be overengineered, but it does the things it sets out to do, and is more approachable (for me at least) than quelpa or the other options. We can make the same argument around emacs itself: Im really impressed of the project page, complex documentation, but seriously what problem is solved by using this app? I don't know any notable programmers who share their own package list and their configuration is based on emacs.

Me too. The other feature that I really like is to freeze all the packages, for once it works, I don't want it to break on me because a package dependency got updated... At least I would like to do that on my own time.

[deleted]

Straight is like [emerge](https://wiki.gentoo.org/wiki/Emerge) on [Gentoo](https://www.gentoo.org/). It's not for everyone but for the people like the control.

Hey! You are doing a great work! Thank you for maintaining straight.el—it’s been such a nice package manager. Pray tell: what is this new package manager you are working on? What’s the same, and what is different?

what's the repository or the name of your project? I'm curious

> You are doing a great work! Thank you for maintaining straight.el—it’s been such a nice package manager. Thank you. I agree it's a nice package manager. Radon did a great job with the concept. > what is this new package manager you are working on? https://www.github.com/progfolio/elpaca > What’s the same, and what is different? It still builds packages from their source repositories via recipes. The main differences are that it installs packages asynchronously and includes a different UI for finding/operating on packages. The code base is about 40% of the size of straight.el and it is easier to extend. It is still a work in progress, but I have been using it for the past six months. In fact, I use it to install straight so I can still maintain it.

https://www.github.com/progfolio/elpaca I plan on releasing a demo video/announcement for it soon.

I love straight.el, it solves control and sync of my packages across machines especially with its use-package integration. What is the superior alternative?

Thanks for maintaining! I love straight, will you cease your involvement because of your new package? Will it fill the same niche, including playing so nice with use-package?

Thank you for the kind words. For the time being I am continuing to maintain straight.el while developing Elpaca. I do not plan on adding any more significant features to straight.el, but am still addressing bugs and providing support. Radon (the original author) is not as active, but does co-maintain straight.el. > Will it fill the same niche, including playing so nice with use-package? It does fulfill the niche of "package manager which makes contributing back to source repositories easy". As far as use-package goes, I chose to provide a wrapper macro, `elpaca-use-package` for the time being. It's nearly a one-to-one replacement for use-package, but it accounts for Elpaca's asynchronicity. (elpaca-use-package my-package :config (etc)) Works as expected. Proper integration via use-package's keyword API is complicated for our use case. For example, straight's use-package integration is roughly 300 lines of elisp. The macro I provide is roughly 8 lines. I may explore advising use-package so that things work transparently without the wrapper macro, but I've yet to implement anything like that.

Couple questions about that: 1. Will it come with similar use-package integration? 2. Getting org-mode to play nicely with straight can be a hassle due to differing versions being shipped with emacs vs. what may be configured with straight. Is there anything in elpaca that will make this easier to navigate? Thanks!

> Will it come with similar use-package integration? See: https://www.reddit.com/r/emacs/comments/wkwlaf/straightel_as_a_classic_example_of/ijqxnoi/ I'll take a look at implementing something more transparent (which does not require the wrapper macro) today. > Getting org-mode to play nicely with straight can be a hassle due to differing versions being shipped with emacs vs. what may be configured with straight. Is there anything in elpaca that will make this easier to navigate? Agreed. This problem has come up many times in our bug tracker and even puzzled me when I first started using straight. The issue usually is caused by a package the user is installing requiring (perhaps transitively) Org mode prior to the user's declaration for Org mode. This can cause mixed-installation errors. The way Elpaca works is all of the user's package declarations are queued prior to any of them being processed. This ensures that the user's declarations take priority over the dependencies. This should solve that problem for the majority of cases. I'm sure it's still possible to end up in a funky state, but is much harder and should be much more obvious how it is happening.

Excellent, sounds really interesting. And I love the name :D

What simple solution(s) are you comparing straight.el to? It would be easier to answer what's straight gives you over the solutions.

> Radon did a great job with the concept. Radon's done a lot of great work. I dunno if you're here somewhere on Reddit, Radon, but I just wanted to say thank you for all you've added to Emacs! Selectrum was my gateway drug into the small and light package space; I've moved onto Vertico (I think there's [some talk](https://github.com/radian-software/selectrum/issues/598#issuecomment-1121682815) about deprecating Selectrum for Vertico) but I think it's totally safe to say that Selectrum really helped open the door to a lot of these new modular packages coming out.

I'll be keeping an eye on the project. Thanks.

Notable. Steep criteria. Guess I didn’t make the cut.

I really hate long documents on single page like those consult, vertico, embark packs, though they are great packages.

Please name your new project “crooked”

Hahahaha I originally went with Parcel, but that's already a popular JS build tool. I think I'll stick with Elpaca.

>I think the documentation is actually a bit weak for straight (and use-package) because it's a little hard to summarize and organize. Same with other complex packages like Hyperbole. Ouch, I am Hyperventilating, Hyperextending, Hypernatremic and just simply...Hyper over that dig! You may consider Hyperbole Hypertrophic but we just see it as Hypergolic when mixed with Emacs. And hi, Wally :-)

Clearly don't know what you're talking about since straight is used by doom and doom is one of the most popular emacs distributions out there.

Whoah minad fired what could've been heavy shots for other maintainers out of nowhere, but Radon took it really well!

> elpaca That might just be my new #1 all-time favourite elisp library name.

Does it have lock files? I skimmed the docs, couldn't see anything. The closest I saw was `:ref` and `:tag` which I guess might be enough in any case.

Interesting. I have written [my own package manager](https://github.com/emacs-twist/twist.nix) too (in Nix), and I chose not to depend on straight.el, unlike what [nix-straight](https://github.com/nix-community/nix-straight.el) does. The reason is because I do not want to depend on the complex piece of software which is not owned by myself. All FOSS projects not backed commercially will suffer from an issue of maintenance. Do you think elpaca will remain more maintainable than straight.el, even with a dedicated UI?

Yes, there are recipe keywords for `:tag`, `:branch`, and `:ref`. There are also commands to write and load lockfiles, but they are works in progress. I will add them to the README once I've fleshed them out more.

Radon is a kind and practical person in my experience.

Great, looking forward to trying it out again when things are a bit further along.

>The main differences are that it installs packages asynchronously and includes a different UI for finding/operating on packages. I also noticed that this is what [feather.el](https://github.com/conao3/feather.el) does to package.el. So elpaca looks like a straight.el equivalent to package.el + feather.el. It must be a hard work!

No offense intended. It's extremely difficult to succinctly summarize and describe the use-case for such a huge and multifaceted package.

Haven't studied feather.el, but on the surface it does look like it has a similar goal for package.el. Managing asynchronicity does complicate things a bit (a nice built-in elisp library would be ideal, but does not exist yet). I looked at using Chris Wellon's [aio](https://github.com/skeeto/emacs-aio) library, but decided against it. I'm trying to minimize the dependencies Elpaca introduces.

Thanks, and thank you for your bug report regarding JSON support. It should be resolved now.

:)

Interesting. I could see something like Guix (which can be run on a host distro) being useful for this sort of thing. I'm sure someone is out there experimenting with that approach now. I think an elisp solution is more accessible. > The reason is because I do not want to depend on the complex piece of software which is not owned by myself. I don't know if that's possible. I would consider Nix a complex piece of software I do not own. I do agree in principal though, that minimizing dependencies is generally a good idea. > All FOSS projects not backed commercially will suffer from an issue of maintenance. That's one way of looking at it. I would argue that you have more control over that maintenance than a non-free commercial project. If they have to (or decide to) close up shop, you've got no chance of maintaining the original product. FOSS just requires there be willing/able parties to do so. > Do you think elpaca will remain more maintainable than straight.el, even with a dedicated UI? straight.el is six years old and still being used daily by many people. That's a testament both to Radon's original execution and the maintenance/authorship provided by anyone who has contributed to the project. I've been working on straight.el a little over two years because I see the value in the project. I plan on providing maintenance so long as I have the time. I'm aiming to make Elpaca easier to understand and maintain than straight.el. Straight's bootstrapping process is something I still struggle with (after working on the package for a couple of years), so I want to avoid that barrier for would-be contributors. I also have the advantage of building off the lessons learned with straight.el. This lead to a smaller, more modular, package overall (roughly 40% the size of straight.el). The dedicated UI adds more value than it does complexity to the code base.

I've had some interaction with both Daniel (minad) and Radon; they're both polite, considerate, and direct. I think Daniel had been working on Selectrum for some time, so Radon knew where he was coming from I think. Both great people. If all Emacs package maintainers were as considerate as they are, we'd be in an incredible state.

>an elisp solution is more accessible. I am not against this claim, but I am not confident at doing complex work in Emacs Lisp, especially systems programming. I want to avoid it if I can. Nix already provides all the functionalities needed for a reproducible build system, so I take advantage of it. My assumption is that I can trust Nix (but not necessarily all of the individual packages in it) and GNU Emacs. I am following development of package-build, because my work can be seen as a Nix replication of the project. It looks indeed hard to get an Emacs package build system right, which justifies my standing point. The problem is not whether I can control it in theory. It's about whether I can manage it in my time. Nonetheless, a pure Emacs Lisp solution would be more faithful to the philosophy of GNU Emacs. Good luck!

Yeah, shows some great attitude from both! Happy it turned out that way

I know. That’s why I responded in a lighthearted manner. {C-h h d w} displays the WHY-USE.kotl file with a list if use cases, if you are interested. Mot short but not too long either.

Hmm, in the meantime Philip Kaludercic is working on bringing version controlled packages integration to the `package.el` as in: https://amodernist.com/texts/package-vc.html Maybe you could join forces? Though guess elpaca's scope is much wider than simply vc integration. Thank you for maintaining `straight.el`!

I've spoken on IRC w Philip. I think the work he's doing will definitely be an improvement to package.el, but I also think the road is long to getting it to the point where it will be as useful as something like straight.el or Elpaca for developing packages. Frankly, I'd rather spend my time working on the actual problems than the meta-problem of discussing every change on emacs-devel. It's not lost work though, as anyone is free to learn from my ideas and mistakes.

> Frankly, I'd rather spend my time working on the actual problems than the meta-problem of discussing every change on emacs-devel. Ah, yeah. I think I understand what you mean very well. Well, I'll happily give elpaca a go as it seems like a great improvement over straight.el if only I manage to make it work nicely with setup.el. That shouldn't be much of an issue, I think. Thank you for all your work!

Thank you. Please bear in mind that the package is still in early development. I appreciate anyone who has the time to help test this package out, but I don't want anyone sinking too much time into converting their init file over just yet (I'm working on direct use-package keyword integration which should make the transition even easier than it is now testing or otherwise).

Of course, that is understandable. After all you've mentioned somewhere in this thread that when the time comes, you will announce the package with a demo. If I manage to make it work and I spot some bugs here and there, I'll try to create an adequate enough issue on GitHub if that would be helpful.

For those of us who simply clone repos and use use-package’s :load-path when you want to employ a specific branch or contribute to a package, and package.el otherwise, what advantages does straight offer?