Is there a way to pin a package to a specific commit using Straight?

I'm looking for a way to pin packages to specific commits in `straight.el` and I came across this answer here on reddit - https://www.reddit.com/r/emacs/comments/iyzs29/is_there_a_way_to_pin_a_package_to_a_specific/g6frovq/ with this example. (use-package diminish :demand :straight (diminish :host github :repo "myrjola/diminish.el" :tag "v0.45")) but according to the answer this: > But I *think* this only applies to the initial checkout, and the real way is to run `straight-freeze-versions`, which creates a lockfile. Then `straight-thaw-versions` applies whatever versions are in there to the package repos. I think I also saw a `:ref` option in an answer here on reddit but I can't find the either the `:ref` and `:tag` option in the straight README. There is a `:branch` option though and that is the one I want to stick to, but it may not be safe if changes or some fixes which I may not want are backported to it. My idea then is to clone the repo I want, create a branch from the commit hash I want and point straight to it. If I don't make any changes to it than that "branch" will be good with straight forever, and I should be able to use the `:fork` option if I want to retain a reference to the original configuration. Is this cloning and creating an unchanging branch a good idea? I have read about the lockfiles but at this stage it is all a bit much for me. I want something I can wrap my head around for now and get to the advanced stuff later. For instance I want to stick to org 9.3.8 in one of my profiles. Can I set the `:branch` to `release_9.3.8`?

Really the lockfile is *the* way to do this. I'm not sure it should be considered an advanced part of straight. The readme says this: > We support `:branch`, but not `:commit` or `:version-regexp`. To lock a package to a specific commit, use a [lockfile](https://github.com/radian-software/straight.el#lockfile-management). See also [#246](https://github.com/radian-software/straight.el/issues/246) for discussion of extensions to the recipe to support package pinning, which is a planned feature. The lockfile is quite simple in reality: it's just an alist of repo names and the commit hashes you want to use: (("diminish.el" . 1234567890abcdef) ...) ([Real example here](https://git.sr.ht/~woolsweater/.emacs.d/tree/main/item/straight/versions/wool-base.el).) You can even create the file by hand if you want, one package at a time. Straight will still load things that aren't in the lockfile. Its only role is to record the versions that straight will check out in the repos/ dir when you do `straight-thaw-versions`. Other than that you can do whatever you want to the local repos; they will always be loaded in their current state by default.

You may want to try Elpaca, as it supports that directly https://github.com/progfolio/elpaca#recipes .

I tend to wind up working on packages from their installed repos. It's a bit less friction than cloning and then loading manually. Does elpaca do checkouts to a directory and play nice with that style of consumption / development?

Yes it can install from a local directory, you may need to run `elpaca-rebuild` to re-compile a modified package, though.

I managed to get the lockfile system working eventually but it was difficult. Even when I pinned `org` to the commit I wanted `straight` still failed to purge it completely and download the right version from the main repo. Even when it downloaded the right version directly from the `bzg/org-mode` repo it still kept reverting to the built-in one. So I hid the version in `/usr/local/share/emacs` and still editing the lockfile and thawing would not cause `straight` to build the right version. Finally I created a new profile from scratch, copied the `default.el` to it and tried again and that is when it worked. I'm not even sure it worked because of the lockfile or whether it worked because I did a `C-x C-e` on the org configuration manually. I may have to try again without disabling the main org installation to see if that will work, but it looks like it will be easier just to disable it permanently to avoid any future troubles.

I'm not exactly sure what you mean by "from their installed repos", but Elpaca organizes installed packages similarly to straight.el. Installing a package stores the package repository under `$ELPACA_DIR/repos/`, links the built elisp under `$ELPACA_DIR/builds/`, and activates the package. When you `find-library` you will end up in the repository. Both straight and Elpaca are designed to make it easy to develop elisp packages.