straight-x-pinned-packages does not do anything to straight-use-package
What's wrong
I intend to clone a repo using straight-x-pinned-packages to specify the git commit it should clone from.
Currently it only clones HEAD. I had to manually git checkout v4.4.2 on magit to build the package at all.
Directions to reproduce
- set straight-x-pinned-packages
(add-to-list 'straight-x-pinned-packages
'("magit" . "b828afbb4b45641998fb6483a08effb1efb214e1"))
- remove magit from repos and build
rm -rf repos/magit*
rm -rf build/magit*
- have
(let ()
(setf straight-current-profile 'pinned)
(straight-use-package 'magit)
...)
somewhere in your config
4. build fails
5. notice the clone is not b828afbb, and is instead in fact HEAD.
Version information
- Emacs version: 30.1
- Operating system: x86_64-alpine-linux-musl
somehow this disappeared miraculously on my end, idk if its an issue for someone else
It disappeared because of me adding magit to versions/pinned.el actually,
Yes, that's correct: I don't see any attempt in those functions in straight-x to influence the behavior of straight-use-package. Improvements are welcome there.
Quick question because I am writing advice for straight-use-package now -- is there any other way of getting the straight-freeze-versions information other than reading the lock file from disk; like is it persisted in the emacs session anywhere
Is there any particular reason :commit is not supported by straight-use-package, as I was intending to not directly alter straight-use-package through using :commit to get the straight-x-pinned-packages to be respected.
is there any other way of getting the straight-freeze-versions information other than reading the lock file from disk; like is it persisted in the emacs session anywhere
Not at present. See:
https://github.com/radian-software/straight.el/blob/b2a3c5a221912574912c98ae840b7763aec06a73/straight.el#L1745-L1753
Is there any particular reason :commit is not supported by straight-use-package
Not per se, other than nobody has thought through all the implications and checked that supporting it wouldn't have unintended consequences where the behavior wouldn't work as expected in some cases.