This repository has been archived by the owner. It is now read-only.

Let me install Python without X11. #14989

Closed
bwinton opened this Issue Sep 17, 2012 · 22 comments

Comments

Projects
None yet
6 participants

bwinton commented Sep 17, 2012

(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…)

Thanks,
Blake.

Contributor

adamv commented Sep 17, 2012

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?

Contributor

adamv commented Sep 17, 2012

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

Contributor

Sharpie commented Sep 17, 2012

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.

Contributor

jacknagel commented Sep 17, 2012

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.

Contributor

samueljohn commented Sep 18, 2012

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.

Contributor

samueljohn commented Sep 18, 2012

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'

Contributor

adamv commented Sep 19, 2012

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

Owner

MikeMcQuaid commented Sep 19, 2012

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).

Contributor

samueljohn commented Sep 19, 2012

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.

Owner

MikeMcQuaid commented Sep 19, 2012

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.

Contributor

samueljohn commented Sep 19, 2012

@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.

@ghost

ghost commented Sep 19, 2012

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.

Contributor

samueljohn commented Sep 19, 2012

@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 :-)

Contributor

samueljohn commented Sep 19, 2012

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

Owner

MikeMcQuaid commented Sep 19, 2012

@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.

Contributor

samueljohn commented Sep 20, 2012

@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.

Owner

MikeMcQuaid commented Sep 20, 2012

@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.

Contributor

samueljohn commented Sep 20, 2012

The traditional platform-independent UNIX Tk implementation which requires an X11 server, such as the Apple X11.app 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. -- http://www.python.org/download/mac/tcltk/

I found the following on 10.8 CLT-only:
/System/Library/Frameworks/Tk.framework/Versions/8.5/Headers/X11/Xlib.h
and the following on 10.8 Xcode-only:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/System/Library/Frameworks/Tk.framework/Versions/8.5/Headers/X11/Xlib.h

so there is hope.

@ghost

ghost commented Sep 30, 2012

This should be fixed with 8f0c5f7.

Time to close maybe :)

Contributor

adamv commented Sep 30, 2012

Closing, presumed fixed.

@adamv adamv closed this Sep 30, 2012

Contributor

samueljohn commented Sep 30, 2012

thanks @MindTooth, you are right.

@xu-cheng xu-cheng locked and limited conversation to collaborators Feb 16, 2016

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.