Why have rational-use-package?

[theophilusx]

Just wondering why have the rational-use-package module? Given the decision to use straight.el rather than package.el, I don't understand why we also have rational-use-package.el, which will use package.el to install packages instead of just doing

(straight-use-package 'use-package)
(setq straight-use-package-by-default t)

which enables the use of use-package, but without the addition of a second package management framework. Is there something I'm missing here?

[abarocio80]

use-package and straight-use-package doesn't have the same functionality. The first manage configuration of the packages, while the latter its installation and availability.

package.el and straight.el are package managers, but doesn't have any package configuration like use-package.

When using either package.el or straight.el, use-package builds upon those, so it can request them to install the packages that are not in the system, and then it procedes to configure the packages.

[theophilusx]

Yes, I understand the difference between straight-use-package and use-package. However, my point is, if you load rational-use-package.el, then when you do use use-package, it will use package.el to install the package, not straight and now yhou have packages installed via two different methods. On the other hand, you can just configure straight so that use-package will default to using straight rather than package.el, avoid the need to update package-archives and all the rest of the setup in rational-use-package.el (only need to add one line to bootstrap.el and avoid having to use :straight t or :straight (recipie) in your use-package stanzas) and not have two different installation methods for packages.

I raise this question because when I tried using rational-load-package.el and use use-package, the package was installed via package.el (so I ahd both an elpa and a stright subdirectory). I've since removed rational-use-package.el, added the straight configuration so that use-package defaults to straight and now all my use-package stanzas use straight and I have only one installation method for all packages and can use use-package for configuration etc.

The only downside I can see with this setup is that you are now required to manage package dependencies (which package.el can handle automatically).

What I really wanted to know is what is the benefit (if any) of using both package.el and straight.el together or is there some downside to defaulting use-package to use straight rather than package.el?

[abarocio80]

I see your point.

Yes. It is using both: straigt.el (the default in this project) and package.el (the default in emacs). The module actually refresh the contents of package.el.

@daviwil: Is this realy necesary? I have never had to configure package.el when using use-package with straight.el.

Does this module require to use package.el? Besides, it never requires use-package.

[abarocio80]

Maybe this package could be splited to two packages:

• rational-use-package
• rational-package-el

[jeastman]

I'm not sure what @daviwil is intending with this, but maybe it is an attempt to give the user some choice in how they install their own packages?

Since Rational Emacs is meant to be a base configuration which allows users to build upon, giving the user the freedom to use their package installer / package configurator of choice may be necessary. I can imagine the rational-* wrappers of these package tools would help to manage the potential conflicts?

[abarocio80]

Yes. That's why I suggested to split the module: one for package.el and other for use-pckage.

[theophilusx]

Yes, I think I would agree. If you are going to have support for two different package installation solutions, the user should be able to choose which one(s) to use.

As it stands now, the impression is that if you want to use use-package, you need to load the rational-use-package.el module, but it isn't clear that doing so means you will be using package.el and not straight to install the packages.

Perhaps this is just a sign of the need for additional documentation to clarify matters. It isn't a big issue IMO - I was more curious than anything else. Being a long-term Emacs user (30 years) and having used Spacemacs for the last few years, I'm really enjoying this setup and the use of straight. I really like the ability to 'fix' packages 'in place'. For example, I use the dev version of mu4e, but the mu4e bindings provided by the mu4e module of evil-collections is broken (because dev version has changed some function signatures). Being able to either fork evil-collection or modify it in palce provides great flexibility you simply cannot get with package.el. I also love the light-weight aspect - spacemacs is great, but I get tired of dealing with issues in parts of it which a don't need/use and prefer a setup which has only what I want.

[jeffbowman]

I created PR #82 to not use straight to install use-package. Also a few other tweaks: add priorities to prefer "gnu" and "nongnu" elpas over "melpa", don't activate all installed packages, instead prefer to allow use-package, require, autoload, etc to control when a package is activated and/or configured. Also, install use-package from one of the elpas if not installed. Using straight here would pull it from git:master based on melpa recipe.

[jeffbowman]

If you are going to have support for two different package installation solutions, the user should be able to choose which one(s) to use.

Yes. package.el and straight are essentially orthogonal in approach. We would need rational-* packaging wrappers with early customization of some preference so the packages are installed according to the users wishes. As it stands right now, other than the rational-use-package module (assuming my PR is merged) all modules assume the use of straight. This is not bad per se, but if someone is looking to do M-x list-packages to see what needs to be upgraded or to install something new, none of the packages installed from modules will show up there.

My personal preference is to use package.el as it is built in, or if I really want things from git, possibly use quelpa as it does something similar to straight but makes a package installable by package.el and defers.

For this project, we have the principle of preferring things "closer" to core emacs (ie things built-in or built to use things built-in (eglot, vertico, marginalia et.al)), but then we don't use the built in packaging mechanism. straight is a really neat tool, but seems a little out of line for the principles of this project.

[theophilusx]

Jeff Bowman @.***> writes:

For this project, we have the principle of preferring things "closer" to core emacs (ie things built-in or built to use things built-in (eglot, vertico, marginalia et.al)), but then we don't use the built in packaging mechanism. straight is a really neat tool, but seems a little out of line for the principles of this project.

Yes, I understand where you coming from, but am somewhat conflicted on this point. I've been a package.el user since it was first introduced. However, it has been the source of numerous irritations for me and straight.el seems to address those. For example, my mu4e situation. If I was using package.el I would either have to re-configure evil-collection to not use the mu4e module and add evil key bindings manually or downgrade mu4e to an older version which is supported by evil-collection. With straight, it was trivial to fix evil-collection and once the dev version I am using of mu4e is released, I can easily create a PR on evil-collection to get it updated.

Of course, I've only been using straight for a matter of days and perhaps my opinion will change once I have more experience with it, but so far, I'm a convert!

I guess in reality, preferred package management is just going to be a fertile ground for religious wars. We probably just need to design rational emacs setup in such a way as to allow the user to easily select whichever approach they prefer. At any rate, things are just so much better than when I first started using Emacs in the 90s when you would have to search the network for elisp packages, never knew if you had the current/latest version, had no easy way to push fixes back upstream or had any consistent mechanism for reviewing or reporting issues. All of the 'modern' approaches are improvements and I would likely be happy with any of them!

[jeffbowman]

I guess in reality, preferred package management is just going to be a fertile ground for religious wars.

Gosh... I hope not! Each one has its strengths and irritations. What is beautiful about Emacs is we can make tools that work the way we want them to work. Straight is a really cool and well written tool that meets the needs of the people who use it. I'm certainly not against it, even here, it just doesn't seem to line up with the principles of this project. That doesn't make it wrong for use here.

We probably just need to design rational emacs setup in such a way as to allow the user to easily select whichever approach they prefer

Yep, but that might be a bit of a sticky wicket, so I'm looking forward to how the solution will evolve.

At any rate, things are just so much better than when I first started using Emacs in the 90s when you would have to search the network for elisp packages, never knew if you had the current/latest version, had no easy way to push fixes back upstream or had any consistent mechanism for reviewing or reporting issues. All of the 'modern' approaches are improvements and I would likely be happy with any of them!

Oh, absolutely! 100% agree!

[ajxn]

@theophilusx did you had Internet? Back in 1985 we had do download Emacs from 1/2" 9 track tape roles when we needed to install Emacs. We would have been HAPPY with a 1200 bps modem to download extensions from. :-D ( Sorry, and yes, it IS so much better no (and it was a reference to Monty Python) )

As you wrote, I don't mind to use straight nor package.el. Maybe need to write some glue functions/macros to handle the selection of package manager so users can easy change from default? Or is it to complicated, compared to just select one?

[jeffbowman]

Back in 1985 we had do download Emacs from 1/2" 9 track tape Lol!! Here come the neck beards!! Isn't there an xkcd comic along these lines? My first version of emacs was 18 (in 1991), but was pre-installed on IBM AIX 4.3... only they didn't install the info files, so it was pretty hard to use without them and no easily accessible internet (for me) to go find them. I think C-h t worked, but there wasn't a splash screen to tell me, I just lucked into it.

I like the idea of some glue functions, however, I'm not sure that lines up with the intent of the principles. I go back and forth on this one... should we provide our own rolled package manager that wraps straight and package... and others (borg, quelpa, et. al. - where do we draw the line, etc). But maybe we shouldn't as that confuses issues and makes it more challenging to configure (note the large number of hits you get with questions related to adding modules or configuring them in either doom or spacemacs). Prelude has a few wrapper functions to help with package installation, but generally the package install is just package.el so, except for some niftyness when you open a file in a particular major mode and some relevant packages get auto installed for you, its mostly just the list-packages interface. One other consideration, most of the examples on the internet for configuring various packages seems to trend toward use-package. We do provide the rational-use-package module for that case though.

For the moment, I do like the simplicity of what we are doing.

[theophilusx]

Jeff Bowman @.***> writes:

I like the idea of some glue functions, however, I'm not sure that lines up with the intent of the principles. I go back and forth on this one... should we provide our own rolled package manager that wraps straight and package... and others (borg, quelpa, et. al.

• where do we draw the line, etc). But maybe we shouldn't as that confuses issues and makes it more challenging to configure (note the large number of hits you get with questions related to adding modules or configuring them in either doom or spacemacs). Prelude has a few wrapper functions to help with package installation, but generally the package install is just package.el so, except for some niftyness when you open a file in a particular major mode and some relevant packages get auto installed for you, its mostly just the list-packages interface. One other consideration, most of the examples on the internet for configuring various packages seems to trend toward use-package. We do provide the rational-use-package module for that case though.

For the moment, I do like the simplicity of what we are doing.

I'm in a similar frame of mind and it is partly why I originally asked about the purpose of the rational-use-package.el module. IN a recent stream, David mentioned he added that module to enable the use of use-package. This just confuses me further as I seem to be able to use use-package just fine without that module and with just setting straight-use-package-by-default to t. This makes me think there is some subtle pint I'm overlooking, but I have no idea what that might be. As things stand, I'm using straight to install all the packages I use and use-package to configure them with no use of package.el.

I do think that if we try to satisfy all preferences, we will end up with something as complicated as spacemacs or doom (and likely with as many issues and increase in debugging effort). I too think we should be trying to keep things as simple as possible.

In some respects, I suspect that many people don't care a lot about which package management solution is used. Those that do probably have the skills to update the configuration to suit their preferences anyway. My vote is therefore, keep it simple and don't try to be everything to everyone. Stick to preferring built-in functionality (i.e. Emacs core, GNU ELPA and NONGNU ELPA) as much as possible and when selecting other packages, prefer those which build on built-in functionality (vertico/embark over help/ivy, corfu/cape over company, tempel over ysnippets etc).

[jeastman]

See also Issue #94

[bryce-carson]

As it stands now, the impression is that if you want to use use-package, you need to load the rational-use-package.el module, but it isn't clear that doing so means you will be using package.el and not straight to install the packages.

I think that impression could be resolved by renaming the module enitrely.

The module name, rational-use-package, does not help itself and reading the commentary is necessary. The module name does two things

• Imply installation and configuration of use-package package, which it does
• Imply use of package.el, rather than straight.el, which it does

Reading this discussion and looking at documentation and code has given me some jamais vu. I've read the word "use" too many times now. 🤯

For what is it worth, I did look at this module and I read it. I spent perhaps thirty minutes looking at documentation and code this morning and determined that I did not need to use the module, as that would install packages with package.el, which I don't want to use right now.

---

In the end, @theophilusx, this is what I ended up with in my configuration.

;; Package management
(straight-use-package 'use-package)

;; Package consumption
(use-package gitter
         :straight (gitter :type git
                   :host github
                   :repo "xuchunyang/gitter.el"
                   :fork (:host github
                      :repo "dalanicolai/gitter.el")))

The way I interpreted

the documentation on straight.el's use-package integration

was that the new keyword that Straight registers with use-package allows you to install and configure a package with a call only to use-package, rather than the alternative:

(straight-use-package 'gitter)
(use-package gitter)

I mostly use Spacemacs, so I'm familiar with installing a package, then configuring it ((require 'use-package), requiring a given package I want to use) with use-package.