Skip to content


Subversion checkout URL

You can clone with
Download ZIP


Let me install Python without X11. #14989

bwinton opened this Issue · 22 comments

7 participants


(Also, without Tk.)

I promise you, I'm never going to use either of those from Python, and I know Python builds just fine without them, so please, don't make me install XQuartz or whatever. :(

(As a side note, I've commented out the "depends_on :x11" lines in the python and python3 formulas, and brew installed them, everything seems just fine…)



Python has no configure switch to disable Tk support. So probably the modules list source file needs to be edited instead. There's even an upstream (closed) bug report asking Python to let you disable Tk support and the response was basically "meh".

So... pull request accepted?


In, try adding the tk modules to disabled_module_list = []


I'm in favor of having this an an option but... I just want to point out that:

I promise you, I'm never going to use either of those from Python

Is usually the last thing someone says before coming back in a few months with a bug report and neglecting to mention that they did not enable X11/Tk support and we spend a few hours figuring out that is the cause of the problem.


As a side note, I've commented out the "depends_on :x11" lines in the python and python3 formulas, and brew installed them, everything seems just fine…

There are some configurations where it simply will not build without this dependency, so as @adamv said, we would need to explicitly disable tcltk somehow before removing it.


If python fails to build Tk (for example because of a missing X11 header file), it continues to build but without tk support, so we can have the line:

depends_on :x11 unless build.include? 'no-tk'

Whether that is the cleanest possible way...not sure.


Shall I add an option to just do that? @jacknagel how to call that option, if I want it to default to 'with-tk'?

option 'without-tk' 'Build without the Tk GUI framework, so no X11 is needed'


Note that on Snow Leopard it should default to on, since X11 and Tk are present and workable.


Even then I wonder. Personally I think consistency across platforms (particularly as people move away from Snow Leopard) is perhaps worth keeping over e.g. PyTk support on 10.6 (which seems nicheish but I could be wrong).


All valid points. And the default should include Tk. On the other hand some communities (e.g. django & Co) don't need a local GUI toolkit, so why not give them the option to go without Tk.


And the default should include Tk

Unless the user doesn't have X11 (e.g. stock Mountain Lion or Lion with Xcode-only). We're trying to not request people to install it unless it is a hard dependency.


@mikemcquaid My thought was alonge these lines:
In case of missing Xquartz, we still print out the message about missing X11 for brew install python as it is right now (so no silent installation without Tk!), so most people will go and grab Xquartz (which is fine).
Those who look at brew options python might be willing to trade Tk support to avoid Xquartz.


Isn't the way of options to provide the user with choices.

So when it comes to Homebrew, maybe a common way is to be chosen. Wether you serve the full app, with options to downscale, or with options to upscale.
Another thought might be wether some of the options should be automatically chosen, e.g. when Tk is present, Python compiles with support, if not present, it will skip Tk.

Sorry for bringing my thoughts to the table :)

On-topic, Tk is making me unable to get a copy of Python via Homebrew. And I personally would prefer at least an option to get away without X11/Xquartz.


@MindTooth In generell, I would agree. But silently remove Tk is not what I want. That would make our brewed python kind of non-standard and people will point their fingers at homebrew. But for advanced users, I am willing to allow --without-tk just because of the hazzle and size of Xquartz (and because there is nor brew install xquartz).

The "just works" philosophy of homebrew is to find a good set of features instead of let the user google which options he might want to use and which not. So normally we tend to build with a lot of features as long as they don't hurt. E.g. having sqlite support in Python is a good thing to have and I can't think of a reason not to have it.

Having that said, there are some formulae that provide quite a lot of options :-)


Thanks for the pointer @adamv, I'll do a PR with the --without-tk option.


@samueljohn No, we should default to not using X11. If you really insist you can print a warning about X11 not being used. Making "most people" grab XQuartz is not fine and I'd rather not make them look at options.

We're planning on making the defaults for everything eventually --without-x if possible to avoid this situation.


@mikemcquaid now I am confused as I interpreted your earlier posts as saying the opposite o_O

Either we default to depending on X11 and have a standard conform python install or we avoid the Xquartz and go without Tk.

Either way, I think we want an option.

A third option - I still have investigate - would be to look if the X11 libs are actually used or if just some definitions from the headers are used. I noticed that opening a Tk window in python does not launch X11.


@samueljohn sorry for the confusion. If it doesn't open X11 that sounds like it's just using either headers or an independent library that we could include in Homebrew. We want an option either way but it should default to not using X11 unless it's already installed; perhaps printing a warning and/or caveat if there is no X11 and Tk won't be built. I think the option should be added and set like so reasonably ASAP; I did it for pretty much every other formula.


The traditional platform-independent UNIX Tk implementation which requires an X11 server, such as the Apple available as an optional component in all recent Mac OS X releases. 64-bit and 32-bit binaries can be built. While the Python installers downloadable from this website do not support X11 Tk, other distributors of Python for Mac OS X may do so. --

I found the following on 10.8 CLT-only:
and the following on 10.8 Xcode-only:

so there is hope.


This should be fixed with 8f0c5f7.

Time to close maybe :)


Closing, presumed fixed.

@adamv adamv closed this

thanks @MindTooth, you are right.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.