Python app formula dependencies

[mafrosis]

Hi folks - hopefully a simple question regarding python packaging for my CLI app (not a library).

Do I specify dependencies for each supported python version? Or do I need to pin to a specific python version in Homebrew?

Reading the docs, it seems I can only specify a single URL/SHA256 for each dependency, yet wheels are built for each os/arch/python, and thus have a different SHA256.

I cannot use tarballs as numpy takes forever to install when it's not a binary.

Thanks!

[carlocab]

It's simpler to stick to a specific Python version. If you want to support multiple Python versions, you can either:

• create a separate formula for each Python version you support; or,
• use options in the formula to allow the user to choose which Python version to build your app with.

Note that formulae with options are not accepted in homebrew/core (in case you plan to submit it), but you're free to host one in your own tap. You can look at the docs and the Git logs for examples of how to make use of options.

I cannot use tarballs as numpy takes forever to install when it's not a binary.

Why not use the Homebrew numpy formula?

[mafrosis]

Thanks. Seemed to me the right path - but I did want to check before I locked things down to python 3.8. Will my users end up with a sandboxed [email protected] distribution for this app (only cost being disk space)?

Fair point about the Homebrew numpy formula, but honestly, I'd rather not deal with the complexity of dependency management across both pip and homebrew. This app is cross platform by design (as any modern app ought to be imo), so other target environments don't have Homebrew.

[carlocab]

I'd rather not deal with the complexity of dependency management across both pip and homebrew.

Then it sounds like you should just package everything via pip and forget Homebrew altogether, no?

Will my users end up with a sandboxed [email protected] distribution for this app (only cost being disk space)?

Kind of. [email protected] is keg-only, so it's not symlinked into Homebrew's prefix by default. That's a little like being in a sandbox. This isn't true about [email protected], though.

[mafrosis]

Then it sounds like you should just package everything via pip and forget Homebrew altogether, no?

If python packaging (and ruby and npm et al) had a great experience for end users then Homebrew wouldn't exist, no?

For all the great work in the Python world on pip in the last decade, it's still a bit of a minefield. Naturally, I want my end users to have the best experience possible, and on macos that's Homebrew. Equally, I don't want to have to manage the numpy dependency in Homebrew's repo for mac users, and in pip for all the other platforms - my effort should be on coding, not packaging 😎.

FWIW the intent is to script the generation of the .rb file, such that the python dependencies shipped are exactly the same as those tested.

Thanks again for the help 👍 You answered the key question here.

[carlocab]

If python packaging (and ruby and npm et al) had a great experience for end users then Homebrew wouldn't exist, no?

It probably still would, actually. Homebrew also allows you to install software such as zsh, ncurses, llvm, gcc, etc. That's actually really what it's designed for. The fact that the same infrastructure also happens to be useful for distributing Python/Ruby/Node packages is just a convenient side-effect.

Unless by "a great experience" you actually mean that they functioned as system package managers, then I suppose, yea, maybe Homebrew wouldn't exist. Even then, doing pip install gcc still strikes me as very weird, no matter how great the experience actually is.