0

I am considering using straight.el, but reading the docs, I have difficulties to understand whether the particular use cases I am interested in are handled as I hope to. Here are the cases:

  1. I have some packages of my own which are hosted on github. Currently, I have a local git repository, and I git fetch it to a directory within the load-path. So I basically hope that by using straight.el, I could reduce it to one directory, the local git repository. But what happens when I edit a file in this repository? As far as I understand, straight.el will detect the modified file and rebuild the package. But that would mean that I cannot properly develop the package because it will always affect my current setup. So how do we get around that? Would I need, say, spin off a develop branch and tell straight.el to use the master branch? I do not understand how straight.el would handle the case that the current branch is not the branch which should be used for compiling and packaging.

  2. The second use case is actually very similar: I clone a github repo and want to edit it, possible to create a PR. Again, my question is: How do I prevent that my edit destroys my current setup, or that it is destroyed when the repo is fetched again from upstream?

Maybe someone could help me to clarify this. If these use cases are not handled properly, I won't change to straight.el, I guess.

Public Image Ltd.
  • 129
  • 7
  • You may be able to use [git worktrees](https://git-scm.com/docs/git-worktree); that way, the development branch lives in a different directory from the master branch. – NickD May 28 '20 at 00:19
  • Thanks, git worktrees seem to be a good way, yet this is what I actually do, even though w/o using worktrees (I clone locally).I thought that maybe `straight.el` always builds from master and thus would allow me to keep uncommitted changes without interfering with the regular build. I guess I am asking that the function in `straight.el` which recognizes that a package has been modified only considers the committed version, and not the unstaged stuff which I might be still working on... – Public Image Ltd. May 28 '20 at 16:21
  • `straight.el` does not know anything about git (well, not strictly true: it does know how to clone a git repo but that's all): it just looks at the directory where the package is installed and checks if anything is changed. It is up to you to make sure that you don't change anything in there (unless you want a rebuild). At least, that's how I read the doc. – NickD May 28 '20 at 17:20
  • for (1) you can tell straight to build from a specific branch (see the instructions here https://github.com/raxod502/straight.el#the-recipe-format). I think a similar thing would work for (2). Alternatively you could have straight just ignore the package (set straight either to nil or to :type built-in – mclear May 13 '21 at 04:04

2 Answers2

0

You could try using Chemacs to run emacs with different set-up profiles. You can have a profile that runs from a development branch if it's under version control or from a different emacs-user-directiory.

EffusiveStoic
  • 36
  • 4
0

I understand your concerns, but I'm not sure they're founded. Although I'm not a straight expert, I have been using it since at least November 2020. You're welcome to look at my init.

My understanding is that packages are built automatically only on first install. Straight uses (mainly) git to clone a package into the straight/repos directory. There are functions straight-pull-all, straight-pull-package, and a few others which are used to do this. Builds can be manually triggered with straight-rebuild-all or straight-rebuild-package. If straight automatically pulled and built, why would these commands exist interactively?

I maintain a few packages for personal use (here and here). Occasionally, I update and push them. I've always had to manually pull them when using another machine. This sounds precisely like your use case.

I always try to fork whatever package I want to use. This has two consequences. First, it only matches upstream whenever I tell it to; I have to manually update the fork. That locks the system independently of straight. Second, it helps with PRs on Github since you need a fork to do that. This also sounds like one of your use cases.

Finally, just try it out. It sounds like you only have concerns (which are valid). However, those concerns can be confirmed or diffused by trying the system out. Switching to straight was, well, straight forward for me. I just did one package at a time until I got the hang of it. It looks scary and the docs are intimidatingly thorough. Consider, though: there are docs and you control all the source code for all your packages. There is lots of useful information in the Github issues. The main point, however, is it's really as simple as backing up your current .emacs.d and trying straight out. If you don't like it, delete everything and return to your previous packaging system. That was my attitude and I never looked back.

Lorem Ipsum
  • 4,327
  • 2
  • 14
  • 35
  • Thanks for pointing out that forking packages actually also locks the system, that's an interesting observation! Concerning your main point, I fully agree. Just do it. I figured what was hindering me was my lack of understanding of that git(hub) stuff. So I am learning now how to manage forks and PRs from the git command line (and magit), and I am feeling much more comfortable now. I am still not using straight, but I finally feel competent enough to try it -- and I will do it once I have some spare time. – Public Image Ltd. May 14 '21 at 06:45
  • Time is the real killer. I hope your experience, whenever you get around to it, goes well! – Lorem Ipsum May 17 '21 at 19:27