# MacOS pack install without Xcode

**URL:** <https://swi-prolog.discourse.group/t/macos-pack-install-without-xcode/9255>\
**Category:** Pack\
**Created:** [September 8, 2025, 4:39pm UTC](https://swi-prolog.discourse.group/t/macos-pack-install-without-xcode/9255 "2025-09-08T16:39:39Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![ridgeworks](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/ridgeworks/32/886_2.png) [@ridgeworks](https://swi-prolog.discourse.group/u/ridgeworks)\
**Post date:** [September 8, 2025, 4:39pm UTC](https://swi-prolog.discourse.group/t/macos-pack-install-without-xcode/9255/1 "2025-09-08T16:39:39Z")

</div>

Trying to do a pack\_install on a new Mac laptop with no Apple developer tools installed, e.g.,

```prolog
?- pack_install(clpBNR).
% Contacting server at https://www.swi-prolog.org/pack/query ... ok
Installation plan:
  Install clpBNR at version 0.12.2 from https://github.com/ridgeworks/clpBNR.git (downloaded 3,670 times)
Download packs? Y/n? 
xcode-select: note: No developer tools were found, requesting install.
% If developer tools are located at a non-default location on disk, use `sudo xcode-select --switch path/to/Xcode.app` to specify the Xcode that you wish to use for command line developer tools, and cancel the installation dialog.
% See `man xcode-select` for more details.
ERROR: Process "process(path(git),[clone,https://github.com/ridgeworks/clpBNR.git,/Users/rickworkman/.local/share/swi-prolog/pack/clpBNR])": exit status: 1
...

```

Is there some (undocumented?) dependancy on Apple developer tools to install a pack?

---

<div class="post-metadata">

**Author:** ![peter.ludemann](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/peter.ludemann/32/48_2.png) [@peter.ludemann](https://swi-prolog.discourse.group/u/peter.ludemann)\
**Post date:** [September 8, 2025, 5:52pm UTC](https://swi-prolog.discourse.group/t/macos-pack-install-without-xcode/9255/2 "2025-09-08T17:52:15Z")

</div>

> [@ridgeworks](#):
>
> Is there some (undocumented?) dependancy on Apple developer tools to install a pack?

Some packs require a C/C++ compiler … could that be the dependency?

---

<div class="post-metadata">

**Author:** ![ridgeworks](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/ridgeworks/32/886_2.png) [@ridgeworks](https://swi-prolog.discourse.group/u/ridgeworks)\
**Post date:** [September 8, 2025, 6:06pm UTC](https://swi-prolog.discourse.group/t/macos-pack-install-without-xcode/9255/3 "2025-09-08T18:06:30Z")

</div>

> [@peter.ludemann](#):
>
> Some packs require a C/C++ compiler … could that be the dependency?

Nothing but Prolog (and docs) in the packs I’m trying to install.

---

<div class="post-metadata">

**Author:** ![peter.ludemann](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/peter.ludemann/32/48_2.png) [@peter.ludemann](https://swi-prolog.discourse.group/u/peter.ludemann)\
**Post date:** [September 8, 2025, 6:37pm UTC](https://swi-prolog.discourse.group/t/macos-pack-install-without-xcode/9255/4 "2025-09-08T18:37:45Z")

</div>

> [@ridgeworks](#):
>
> Nothing but Prolog (and docs) in the packs I’m trying to install.

Some packs also require `make` or `cmake` – this dependency (and also the “build steps”) isn’t terribly well documented. (Assuming that `make` is part of Xcode.) Pack installation uses the [build](https://www.swi-prolog.org/pldoc/doc/_SWI_/library/build/index.html) library that allows various “make”-like plugins, and it might be looking for something that requires Xcode?

(I don’t understand many of the details of installing packs, so I’ve been reading the code to improve its documentation, but haven’t got very far.)

---

<div class="post-metadata">

**Author:** ![ridgeworks](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/ridgeworks/32/886_2.png) [@ridgeworks](https://swi-prolog.discourse.group/u/ridgeworks)\
**Post date:** [September 9, 2025, 2:56pm UTC](https://swi-prolog.discourse.group/t/macos-pack-install-without-xcode/9255/5 "2025-09-09T14:56:51Z")

</div>

Following up: this has something to do with loading from a git repo. If I use a URL of an archived version, it works:

```prolog
?- pack_install('https://github.com/ridgeworks/clpBNR/archive/refs/tags/v0.12.1.zip').
Installation plan:
  Install clpBNR at version 0.12.1 from https://github.com/ridgeworks/clpBNR/archive/refs/tags/v0.12.1.zip
Download packs? Y/n? 
% Downloading clpBNR ... 2,405,133 bytes
% Contacting server at https://www.swi-prolog.org/pack/query ... ok
true.

?- [library(clpBNR)].
% ***clpBNR v0.12.1***.
% Arithmetic global flags will be set to prefer rationals and IEEE continuation values.
true.

```

---

<div class="post-metadata">

**Author:** ![jan](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/jan/32/4_2.png) [@jan](https://swi-prolog.discourse.group/u/jan)\
**Post date:** [September 9, 2025, 3:30pm UTC](https://swi-prolog.discourse.group/t/macos-pack-install-without-xcode/9255/6 "2025-09-09T15:30:24Z")

</div>

> [@ridgeworks](#):
>
> Following up: this has something to do with loading from a git repo. If I use a URL of an archived version, it works:

This is confirmed by the error message:

> [@ridgeworks](#):
>
> ```prolog
> xcode-select: note: No developer tools were found, requesting install.
> % If developer tools are located at a non-default location on disk, use `sudo xcode-select --switch path/to/Xcode.app` to specify the Xcode that you wish to use for command line developer tools, and cancel the installation dialog.
> % See `man xcode-select` for more details.
> ERROR: Process "process(path(git),[clone,https://github.com/ridgeworks/clpBNR.git,
> 
> ```

Installing from a git repo uses git to download the pack. Actually, AFAIK, it checks that `git` is a known executable and then uses git. Otherwise, for known git servers (only github I think for now), it downloads the files as tar archive. But, MacOS seems to have a dummy `git` executable that triggers activating Xcode ☹ There is a finite amount of weird environments we can handle …

---

<div class="post-metadata">

**Author:** ![Boris](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/boris/32/7486_2.png) [@Boris](https://swi-prolog.discourse.group/u/Boris)\
**Post date:** [September 9, 2025, 3:38pm UTC](https://swi-prolog.discourse.group/t/macos-pack-install-without-xcode/9255/7 "2025-09-09T15:38:19Z")

</div>

> [@jan](#):
>
> But, MacOS seems to have a dummy `git` executable that triggers activating Xcode ☹ There is a finite amount of weird environments we can handle

This has been fixed for newer Mac OS version but some years ago I still regularly experienced a problem with git every time the OS got an update. There is [this rant](https://swi-prolog.discourse.group/t/xpce-on-mac/3642/11) from some years back, the message is that I periodically had to run

```prolog
$ xcode-select --install

```

to fix `git` among other things. I had installed git with `homebrew`.

---

<div class="post-metadata">

**Author:** ![ridgeworks](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/ridgeworks/32/886_2.png) [@ridgeworks](https://swi-prolog.discourse.group/u/ridgeworks)\
**Post date:** [September 9, 2025, 4:10pm UTC](https://swi-prolog.discourse.group/t/macos-pack-install-without-xcode/9255/8 "2025-09-09T16:10:38Z")

</div>

> [@jan](#):
>
> But, MacOS seems to have a dummy `git` executable that triggers activating Xcode ☹ There is a finite amount of weird environments we can handle …

Indeed the message is coming from the dummy `git`:

```prolog
% git -help
xcode-select: note: No developer tools were found, requesting install.
If developer tools are located at a non-default location on disk, use `sudo xcode-select --switch path/to/Xcode.app` to specify the Xcode that you wish to use for command line developer tools, and cancel the installation dialog.
See `man xcode-select` for more details.

% 

```

> [@Boris](#):
>
> the message is that I periodically had to run
> 
> ```prolog
> $ xcode-select --install
> 
> ```
> 
> to fix `git` among other things.

From the `xcode-select` man page:

```prolog
       --install
              Opens a user interface dialog to request automatic installation
              of the command line developer tools.

```

So the answer is yes, the package manager on Mac’s does have a dependancy on the MacOS developer tools. I think this applies in general though, i.e., some level of `git` support must be available on the platform to install packs from `git` repos. Perhaps that support requirement could be more clearly be described in the package manager documentation somewhere.

---

<div class="post-metadata">

**Author:** ![ridgeworks](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/ridgeworks/32/886_2.png) [@ridgeworks](https://swi-prolog.discourse.group/u/ridgeworks)\
**Post date:** [September 9, 2025, 4:22pm UTC](https://swi-prolog.discourse.group/t/macos-pack-install-without-xcode/9255/9 "2025-09-09T16:22:44Z")

</div>

> [@Boris](#):
>
> This has been fixed for newer Mac OS version

BTW, this is on MacOS 15.6.1, so pretty recent.

---

<div class="post-metadata">

**Author:** ![jan](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/jan/32/4_2.png) [@jan](https://swi-prolog.discourse.group/u/jan)\
**Post date:** [September 9, 2025, 4:24pm UTC](https://swi-prolog.discourse.group/t/macos-pack-install-without-xcode/9255/10 "2025-09-09T16:24:09Z")

</div>

> [@ridgeworks](#):
>
> Perhaps that support requirement could be more clearly be described in the package manager documentation somewhere.

As most people do not read the docs and it is hard to keep them in sync with the implementation, I guess a good error message is as good as it gets. Normally, I think it will raise an existence error for `source_sink` `path(git)`. That can probably be improved a little. Few people will interpret this correctly. In any case, if there is a program called `git` that does something different, it gets hard ☹

---

<div class="post-metadata">

**Author:** ![jan](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/jan/32/4_2.png) [@jan](https://swi-prolog.discourse.group/u/jan)\
**Post date:** [September 9, 2025, 4:31pm UTC](https://swi-prolog.discourse.group/t/macos-pack-install-without-xcode/9255/11 "2025-09-09T16:31:54Z")

</div>

> [@jan](#):
>
> I think it will raise an existence error for `source_sink` `path(git)`. That can probably be improved a little.

Actually, this has been done. You get this error if `git` is missing.

```
ERROR: Could not find executable file "git" in $PATH

```

That is reasonable, no?

---

<div class="post-metadata">

**Author:** ![ridgeworks](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/ridgeworks/32/886_2.png) [@ridgeworks](https://swi-prolog.discourse.group/u/ridgeworks)\
**Post date:** [September 9, 2025, 5:02pm UTC](https://swi-prolog.discourse.group/t/macos-pack-install-without-xcode/9255/12 "2025-09-09T17:02:45Z")

</div>

> [@jan](#):
>
> As most people do not read the docs and it is hard to keep them in sync with the implementation,

That’s usually an issue and can a good error message be produced when there is a dummy `git`? Currently you get:

```prolog
ERROR: Process "process(path(git),[clone,https://github.com/ridgeworks/clpBNR.git,/Users/rickworkman/.local/share/swi-prolog/pack/clpBNR])": exit status: 1

```

Here pointing to `process(path(git), ...` doesn’t help a lot either, i.e., what’s the root cause?

> [@jan](#):
>
> In any case, if there is a program called `git` that does something different, it gets hard ☹

Maybe a better `git` check would also help, e.g., at least ensuring that `git --version` returned a sensible answer. (Intentional dummy commands tend to just provide hints for the user.)

For the docs, I was thinking that a general statement indicating that `git` support (i.e., the `git` command must be findable?) is a requirement would at least point users at the root cause, even if directly address the MacOS issue. (IMO people tend to read the docs much more carefully when error messages aren’t helpful.)

---

<div class="post-metadata">

**Author:** ![jan](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/jan/32/4_2.png) [@jan](https://swi-prolog.discourse.group/u/jan)\
**Post date:** [September 10, 2025, 8:21am UTC](https://swi-prolog.discourse.group/t/macos-pack-install-without-xcode/9255/13 "2025-09-10T08:21:03Z")

</div>

> [@ridgeworks](#):
>
> Intentional dummy commands tend to just provide hints for the user.)

On a Mac you never know. They have gcc, which is just an alias for clang. True, it works most of the time, but it is not gcc. They have libreadline, which is just a wrapper around libedit that is far from a complete libreadline, etc.

As far as I’m concerned this as it is. If it is resolved in the latest MacOS it will die away as an issue. Before, Google can find this and I think an LLM can tell you what is wrong 🙂 They are fairly good in explaining error reports in my experience …

Note that you not need git for installing github hosted packs. You only should not have a broken git. I’ll accept a PR that verifies that git is sane.

---

<div class="post-metadata">

**Author:** ![ridgeworks](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/ridgeworks/32/886_2.png) [@ridgeworks](https://swi-prolog.discourse.group/u/ridgeworks)\
**Post date:** [September 10, 2025, 2:49pm UTC](https://swi-prolog.discourse.group/t/macos-pack-install-without-xcode/9255/14 "2025-09-10T14:49:29Z")

</div>

> [@jan](#):
>
> Note that you not need git for installing github hosted packs. You only should not have a broken git. I’ll accept a PR that verifies that git is sane.

PR proposal follows.

`prolog_pack.pl` contains the following test:

```prolog
have_git :-
    process_which(path(git), _).

```

MacOS’s dummy `git` command returns a non-zero exit code (see error trace earlier in this thread), so change the test as follows:

```prolog
have_git :-
	catch(run_process(path(git),['--version'],[output(_),error(_)]),
	      error(process_error(_,_),_),
	      fail
	     ).

```

This succeeds or fails silently depending on whether the `git --version` command generates an error. Seems to do the right thing on systems with the dummy `git` and an operational `git`. In particular it can install packs on MacOS without requiring any developer tools.

Unless there are suggestions for improving this, I’ll generate a PR.

---

<div class="post-metadata">

**Author:** ![ridgeworks](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/ridgeworks/32/886_2.png) [@ridgeworks](https://swi-prolog.discourse.group/u/ridgeworks)\
**Post date:** [September 12, 2025, 4:39pm UTC](https://swi-prolog.discourse.group/t/macos-pack-install-without-xcode/9255/15 "2025-09-12T16:39:56Z")

</div>

The test above (Does “git --version” result in a non-zero exit code?) has the intended effect when loading SWIP packs. However running the imposter `git` has an undesirable side effect (IMO) of a nagging MacOS dialog directing the user to download the Xcode command line tools.

So an alternative proposal:

```prolog
have_git :-
    process_which(path(git), _),
    catch(run_process(path(man),['-w', 'git'],[output(_),error(_)]), % silent
          error(Err,_),
          \+ Err = process_error(_,_) % will succeed if no 'man' command
         ).

```

`have_git` now succeeds if there is a findable `git` command _and_ a `man` page. This has the desired effect on MacOS without the “nag” since the test does not actually require the (possibly imposter) `git` command to be run.

I think this is platform agnostic. The findable command is the same as the current test and the `man` page test only fails when a `man` command exists and the `git` man page does not.

Comments welcome.

P.S.

> [@jan](#):
>
> Note that you not need git for installing github hosted packs.

Begs the question of why the `git` command is used at all?

---

<div class="post-metadata">

**Author:** ![jan](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/jan/32/4_2.png) [@jan](https://swi-prolog.discourse.group/u/jan)\
**Post date:** [September 13, 2025, 9:34am UTC](https://swi-prolog.discourse.group/t/macos-pack-install-without-xcode/9255/16 "2025-09-13T09:34:58Z")

</div>

> [@ridgeworks](#):
>
> Begs the question of why the `git` command is used at all?

Using git for git package URLs works reliably on any git repo. How to download a snapshot as.(tar) archive using HTTP varies between installations (if possible at all).

Then, updating the package when cloned as git repo is cheaper and you can use git to jump between versions, examine changes, prepare local changes and create a PR, etc. I think it would be a good idea to use git for all packages as it is simply more controlled. When downloaded from one of the main services, there is also some amount of community and vulnerability tracking.

---

<div class="post-metadata">

**Author:** ![ridgeworks](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/ridgeworks/32/886_2.png) [@ridgeworks](https://swi-prolog.discourse.group/u/ridgeworks)\
**Post date:** [September 13, 2025, 1:29pm UTC](https://swi-prolog.discourse.group/t/macos-pack-install-without-xcode/9255/17 "2025-09-13T13:29:25Z")

</div>

Just to be clear, I wasn’t suggesting that packs shouldn’t be served from git repos. I was only questioning whether `library(prolog_pack)` should use the local `git` command if it isn’t necessary to do so. Is there some other advantage, e.g., reliability or performance?

---

<div class="post-metadata">

**Author:** ![jan](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/jan/32/4_2.png) [@jan](https://swi-prolog.discourse.group/u/jan)\
**Post date:** [September 13, 2025, 2:27pm UTC](https://swi-prolog.discourse.group/t/macos-pack-install-without-xcode/9255/18 "2025-09-13T14:27:08Z")

</div>

> [@ridgeworks](#):
>
> Is there some other advantage, e.g., reliability or performance?

I think my previous message contains enough motivation. You can check out git\_archive\_url/3 in library(prolog\_pack) to see how fragile the alternative is. That is only for github. There is AFAIK no general alternative for using a git client. We can of course bundle a git client with SWI-Prolog, but that seems overkill.

---

<div class="post-metadata">

**Author:** ![ridgeworks](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/ridgeworks/32/886_2.png) [@ridgeworks](https://swi-prolog.discourse.group/u/ridgeworks)\
**Post date:** [September 13, 2025, 3:50pm UTC](https://swi-prolog.discourse.group/t/macos-pack-install-without-xcode/9255/19 "2025-09-13T15:50:13Z")

</div>

> [@jan](#):
>
> You can check out git\_archive\_url/3 in library(prolog\_pack) to see how fragile the alternative is.

“fragile” is a subjective term but from the doc:

```prolog
%! git_archive_url(+URL, -Archive, +Options) is semidet.
%
% If we do not have git installed, some git services offer downloading
% the code as an archive using HTTP. This predicate makes this
% translation.

```

So it sounds like using the `git` command will work with a potentially broader range of repos and I guess that’s a good enough reason.

EDIT: Yes I now see your point - `git_archive_url/3` only succeeds with `github.com`.

---

<div class="post-metadata">

**Author:** ![jan](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/jan/32/4_2.png) [@jan](https://swi-prolog.discourse.group/u/jan)\
**Post date:** [September 14, 2025, 7:02am UTC](https://swi-prolog.discourse.group/t/macos-pack-install-without-xcode/9255/20 "2025-09-14T07:02:04Z")

</div>

> [@ridgeworks](#):
>
> EDIT: Yes I now see your point - `git_archive_url/3` only succeeds with `github.com`.

And worse, the implementation assumes various details on translating the git repo path and even change the host from which to download. I think there is no guarantee this will stay like this forever. There is simply no official GIT API to do this ☹ .

The best option for not relying on git is probably to create a Prolog library embedding a git client library. That seems an overkill. We could also write a git client in Prolog 🙂 . Actually, the logic to assemble and disassemble git objects is available in Prolog and used by the SWISH file store.