search

melpa / package-build

Tools for assembling a package archive
https://github.com/melpa/melpa
25 stars 34 forks source link

Allow timeout "command" to inherit variables || Make quelpa & package-build inherit GIT_EXEC_PATH variable #76

Closed imme-emosol closed 1 year ago

imme-emosol commented 1 year ago

"should ask melpa/package-build" ~ posted in https://github.com/syl20bnr/spacemacs/issues/15933#issuecomment-1441516185 "

Hi, I have a weird GIT-configuration to allow me to run some customized git programs by default.

However, the usual GIT_EXEC_PATH="/usr/lib/git-core" emacs did not work for spacemacs, perhaps because of the timeout wrap around git.

I can make the startup errors go away by replacing command in package-build--run-process ( core/libs/package-build.el ) & in quelpa-build--run-process ( core/libs/quelpa.el ) with: "env" "GIT_EXEC_PATH=/usr/lib/git-core" command

Would it be possible (and sensible) to allow variables to be "known" to the (git) command? So that, for example GIT_EXEC_PATH="/usr/lib/git-core" emacs would work.

tarsius commented 1 year ago

Did you add the directory where your custom git binary is installed to $PATH (not just in your shell but for Emacs as well)?

Would it be possible (and sensible) to allow variables to be "known" to the (git) command?

I don't think it would be sensible for every package that calls git to add an option that would allow it to work with your apparently weird setup. It seems you have to figure out how to adjust your configuration to make it unnecessary to make changes elsewhere.

imme-emosol commented 1 year ago

I do not have a custom built git, in GIT_EXEC_PATH there are only custom builds of gitk & git-gui.

This requires me to work around "git's subcommand resolving" to run certain git-commands. For instance for mergetool i execute the command: GIT_EXEC_PATH="/usr/lib/git-core" git mergetool

Which is why i expected GIT_EXEC_PATH="/usr/lib/git-core" emacs to work as well, but it does not, neither does ( export GIT_EXEC_PATH="/usr/lib/git-core" ; emacs )

It gives me "git: 'remote-https' is not a git command.", which is probably because git is started with my default GIT_EXEC_PATH that is missing quite some git-programs, such as git-remote-https.

imme-emosol commented 1 year ago

Of course, feel free to close this issue if this is too strange a situation to take into account.

tarsius commented 1 year ago

I do not have a custom built git, in GIT_EXEC_PATH there are only custom builds of gitk & git-gui.

At least the former is a binary. If the latter is too, it might be enough to symlink those into $PATH.

This requires me to work around "git's subcommand resolving" to run certain git-commands. For instance for mergetool i execute the command: GIT_EXEC_PATH="/usr/lib/git-core" git mergetool

I believe this should not be necessary. I am under the impression you go about it the wrong way. First make sure git works without requiring any shenanigans. Only then try making your custom build of secondary tools available.

Of course, feel free to close this issue if this is too strange a situation to take into account.

Yeah, I don't think it makes sense to add any kludges to this package.