You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When the path to a local package is inside a version-controlled directory, would it be desirable in principle for pak to keep a record of its commit hash at install time?
When debugging dev packages I often want to know which commit I installed from, and have come to really appreciate how easy it is to get that from the RemoteSha field when a package was installed from GitHub or R-universe.
For packages installed locally this doesn't seem to be recorded, and from #621 (comment) I suspect that may be intentional. I agree with that comment that I don't want pak to make upgrade decisions based on the state of a local directory, but could the mentioned "we could add it and ... use for other things in the future" include providing a sha for runtime diagnostics?
(For context, I ask because I just hand-rolled a hash-recording step in the build script for one of my internal packages and thought "Well, that works, but this entire script ought to just be pak::local_install()" 😄 )
The text was updated successfully, but these errors were encountered:
It is not trivial to decide if a local directory has an up to date sha, we'd probably need to call git, which is not so great in itself, plus there are a lot of edge cases.
Thinking through the process, I think what I'm picturing here is (roughly equivalent to?) the ability to pass a local path to the git:: package source, which probably implies "that would mean implementing support for the Git local transport protocol." Definitely not a small change.
When the path to a local package is inside a version-controlled directory, would it be desirable in principle for pak to keep a record of its commit hash at install time?
When debugging dev packages I often want to know which commit I installed from, and have come to really appreciate how easy it is to get that from the
RemoteSha
field when a package was installed from GitHub or R-universe.For packages installed locally this doesn't seem to be recorded, and from #621 (comment) I suspect that may be intentional. I agree with that comment that I don't want pak to make upgrade decisions based on the state of a local directory, but could the mentioned "we could add it and ... use for other things in the future" include providing a sha for runtime diagnostics?
(For context, I ask because I just hand-rolled a hash-recording step in the build script for one of my internal packages and thought "Well, that works, but this entire script ought to just be
pak::local_install()
" 😄 )The text was updated successfully, but these errors were encountered: