Use python3 by default in a formula

[lelegard]

Hi,

This sounds like a recurrent topic but I couldn't find a nice way to solve it in the context of a formula. I do not even know if this is a problem in the context of a formula.

Consider a C++ tool with complex build scripts and an existing formula for previous versions. Python is now used during the build because some build scripts are now written in Python and I need to adapt the formula. Those scripts start with #!/usr/bin/env python. Note "python", not "python3". But Python3 is required. So, the command python must be set to python3 by default.

The scripts cannot be modified with #!/usr/bin/env python3 because it won't work on Windows and some Linux distros. I need python3 as default. Many Linux distros have clean ways to do this, either using alternatives or packages such as python-is-python3.

What is the right way to do this in Homebrew, and specifically in the context of a formula?

On my Mac, python is linked to python3 in /usr/local/bin but I suspect I did some ln -s years ago. On a fresh install, in a macos-latest CI runner of GitHub for instance, brew install python3 leaves python linked to python2.

How would I solve this in a Homebrew formula? Is it acceptable to force the ln -sf python3 python? How do you solve /usr/local vs. /opt/homebrew in a portable way?

Thanks

[carlocab]

To be clear, do you only need to make sure that you can invoke Python3 as python at build-time? (As opposed to also at runtime, etc.)

If so, declaring a dependency on one of the Python formulae should suffice.

[lelegard]

To be clear, do you only need to make sure that you can invoke Python3 as python at build-time? (As opposed to also at runtime, etc.)

Yes

If so, declaring a dependency on one of the Python formulae should suffice.

Are you sure? On a fresh GitHub CI runner with brew and python 2 & 3 pre-installed, an explicit "brew install python3 python" results in "already installed" messages and python linked to python2. And the build failed.

Is there some "sandbox" to test Homebrew formulae? To make sure it works in a Homebrew CI runner. Because all brew testing commands run on my Mac, using my python config, potentially not the same as the one in a Homebrew CI runner. I would not like to submit a PR resulting in a failing build in homebrew-core when the new version is ready and released everywhere else.

[carlocab]

You can submit a PR for a pre-release version so we can test it out in CI and have a look. Just please indicate in the PR that it is a pre-release so we won't merge it.

[lelegard]

Thanks. How do we mark a PR as "pre-release", meaning "do not publish in Homebrew even if it succeeds to build"?

[carlocab]

Just say so in the PR body and title. Someone will add the appropriate label later.

[lelegard]

If so, declaring a dependency on one of the Python formulae should suffice.

Using depends_on "python3" => :build, the audit gives the following error:

  * Dependency 'python3' is an alias; use the canonical name 'python@3.10'.

I would expect a dependency on python3 to pull the latest Python 3.x. I don't mind specifying python@3.10 but what will happen when Python 3.11 or 3.12 are released, if I do not update my dependency? It will probably pull Python 3.10 exactly. And other formulae, depending on their level of update, may also pull 3.11 or 3.12 explicitly. I understand now why my Homebrew system has so many different accumulated versions of Python.

Isn't there a way to say "depends on Python3, the latest one, no need to accumulate some many different Python environments"?

[SMillerDev]

There is not, but other contributors will try and update al 3.10 dependents when 3.11 arrives.

---

If you want to get rid of dependencies that you didn't specifically install that aren't needed anymore, use brew autoremove

[lelegard]

@carlocab

You can submit a PR for a pre-release version so we can test it out in CI and have a look. Just please indicate in the PR that it is a pre-release so we won't merge it.

I submitted that PR: Homebrew/homebrew-core#113051

This is a small standalone test, not a pre-release of the full project which takes time to build. Not to be merged of course, just to run the CI.

[carlocab]

It seems to find Python3 as python just fine. I don't think there's a need to test this any further. I was interested in a CI test because I misinterpreted this

Are you sure? On a fresh GitHub CI runner with brew and python 2 & 3 pre-installed, an explicit "brew install python3 python" results in "already installed" messages and python linked to python2. And the build failed.

to mean that you had attempted a formula build on a pre-release version.

Doing brew install python[3] is not equivalent to declaring a dependency on one of the Python formulae. This is why clarifying whether you needed it only for the build instead of also at runtime was relevant.

So, I guess to answer your question regarding my being sure: yes, I am sure.

[lelegard]

OK, thanks 👍