python without tk

farphel · 2003-12-24 01:15:30

Would it be possible to split the python package into one that does not require tk (and therefore X) to be installed? I'm a big fan of python and use it for server scripts and don't like running X on servers.

I believe all it would require is a "--without-tk" to the configure script in the PKGBUILD to produce a tk-less python package. At least that's what I do via abs.

Thanks in advance,
farphel

contrasutra · 2003-12-24 02:14:02

Just use the -d flag when installing.

We shouldn't have to have 10 different builds of apps just to accomodate people without X.

Tk should be built in because its the standard cross-platform GUI for python.

farphel · 2003-12-24 12:09:44

contrasutra wrote:

Just use the -d flag when installing.

Maybe it's just my background with other distros, but this doesn't seem like the best solution. If you're going to use -d for installing packages, why not just use slackware or some other distro that doesn't do dependency checking, or just quit using pacman?

contrasutra wrote:

We shouldn't have to have 10 different builds of apps just to accomodate people without X.

I thought one of the goals of Arch was to provide "lean" packages. And it's not just X, but any packages that have large external dependencies. For example, when building apps that have GNOME support, I would argue that there should be two packages, one with GNOME and one without.

contrasutra wrote:

Tk should be built in because its the standard cross-platform GUI for python.

I wouldn't call it the "standard", but maybe the "first". And it's not part of the standard python distribution. If that were so, the python.tgz would contain Tk, and the docs on python.org would have sections describing it.

This is actually another reason why Tk should NOT be included in the Arch python package - it's NOT part of the standard distribution or builtin library.

hApy · 2003-12-27 21:47:30

farphel wrote:

Maybe it's just my background with other distros, but this doesn't seem like the best solution. If you're going to use -d for installing packages, why not just use slackware or some other distro that doesn't do dependency checking, or just quit using pacman?

ok that's a little extreme.

I thought one of the goals of Arch was to provide "lean" packages. And it's not just X, but any packages that have large external dependencies. For example, when building apps that have GNOME support, I would argue that there should be two packages, one with GNOME and one without.

well I would say it should come down to how often python & tk are used together -- is everybody just going to have to re-build it with tk support anyways? (I have no idea about this personally) If the majority of people need tk support and the package still works perfectly after being installed with the -d flag & no X, then it makes more sense to leave it enabled, and make the minority of users who *really* want to make it that little bit leaner to re-compile it without tk support using ABS.

farphel · 2003-12-27 22:23:28

hApy wrote:

farphel wrote:
Maybe it's just my background with other distros, but this doesn't seem like the best solution. If you're going to use -d for installing packages, why not just use slackware or some other distro that doesn't do dependency checking, or just quit using pacman?
ok that's a little extreme.

Hey, I'm all about Xtreme examples, dude...

hApy wrote:

well I would say it should come down to how often python & tk are used together -- is everybody just going to have to re-build it with tk support anyways? (I have no idea about this personally) If the majority of people need tk support and the package still works perfectly after being installed with the -d flag & no X, then it makes more sense to leave it enabled, and make the minority of users who *really* want to make it that little bit leaner to re-compile it without tk support using ABS.

Actually, I think a better solution would be to provide two packages in this case: "python" and "pythontk". The pythontk package would depend on the base python package. Installing pythontk would only install the python Tk module and not contain reduntant modules from the base python package. This is exactly how the Arch perl and perltk packages work. Why not follow suite for python?

contrasutra · 2003-12-27 22:52:09

I do consider tk "standard". In fact, IDLE, the Python IDE that comes with the distribution uses TK, so we need to build it.

farphel · 2003-12-28 01:14:30

IDLE is just one of many programs distributed with the python source under its Tools directory. If you read the top level README that documents the installation/build process for python, IDLE is not mentioned at all. Tkinter is mentioned, but only saying that if you have Tcl/Tk installed, the Tkinter modules will be built.

If Tk (or Tkinter rather) was part of the "standard" python distribution, it would include a copy of libtk from Tcl/Tk (PHP for example ships with a copy of libmysqlclient).

I don't see why the package maintainer can't build a python and a pythontk package (that could also contain IDLE). If the answer is to say that Tk can't/won't be split out of python, then shouldn't perl and perltk be merged?

I just think having python require Tk, which in turn requires X, goes against the Arch design goals. Perhaps I should have just submitted a bug report rather than start a discussion about wether or not Tk is part of python.

Xentac · 2003-12-28 02:02:19

The difference between perl/perltk and python/pythontk is that perltk is actually a seperate module, pythontk is distributed with the base python tarball.

It is totally possible to split out the tk part of python and build another package. After all Debian does it... oh right... I forgot... everyone likes to use Debian as an example of what not to do...

One of the package design decisions that's been around since before I started is that no packages would be artificially split. That is, nothing the upstream developers meant should be together should be split into seperate pieces. If the upstream developers split it, then we'd have two packages, otherwise we leave it as one.

Splitting packages also makes for a maintenance nightmare.

Arch's design goals is to be simple and cut out all the crap. To do this we try to offer all the commonly used options in our packages and then let users rebuild as they see fit. There is a difference between bare minimum and Arch's goals.

I think that discussing it is better because it's a community decision. What does the community want done with it's packages? Not how does one person want their packages personalized...

I'm not voting either way here. I'm just clearing what I see as some misconceptions up. Please continue the arguing.

farphel · 2003-12-28 13:46:01

Xentac wrote:

The difference between perl/perltk and python/pythontk is that perltk is actually a seperate module, pythontk is distributed with the base python tarball.

You're right about perl/perltk. However, I think the python/pythontk is a bit of a grey area. Python ships with Tk support (a module called Tkinter), but the only way it is built is if the host system already has Tcl/Tk installed. If Tk is not installed and you compile python from source, you do not get Tkinter (or IDLE). If python is built without Tkinter, it does not in any way affect python, its performance, or its usability. That's why I feel that having the python package require Tk is a mistake.

Xentac wrote:

One of the package design decisions that's been around since before I started is that no packages would be artificially split. That is, nothing the upstream developers meant should be together should be split into seperate pieces. If the upstream developers split it, then we'd have two packages, otherwise we leave it as one.

Thanks for the clarification, Xentac. This sheds some insight onto why python requires Tk.

Xentac wrote:

Splitting packages also makes for a maintenance nightmare.

Well, your point is valid for packages with many compile options, or possible dependencies on other software. In this case, I don't think it would be that bad to have to monitor upstream python release and rebuild an additional pythontk package. However, your point is well taken. Afterall, the reason why I'd rather see the python package split up is so that I (as an end-user) do not have to deal with it but would rather have an Arch package maintainer deal with it. I know that sounds lazy, but oneof the reasons I love Arch so much is that the package maintainers do such an excellent job keeping up with new versions and providing solid packages. I'd like to continue relying on them!

Xentac wrote:

Arch's design goals is to be simple and cut out all the crap.

That's one of my peeves with this too. I consider Tk extra "crap". If I were to write a GUI using python, I would rather use pyGTK or pyQT (both of which are also platform independent). Of course this is a personal opinion.

Xentac wrote:

I'm not voting either way here. I'm just clearing what I see as some misconceptions up. Please continue the arguing.

I'm guessing it will be difficult to rely on community opinion to drive this decision. How many professional python programmers are using Arch? Do they write GUIs using Tkinter? Would all of those people care to weigh in on the discussion? And yes, I basically program in python exclusively for my day job. I'm not saying that that entitles me to a better opinion. It's just that when it comes time to deploy my python applications on a sserver, I want my server to be as lean as possible. If I have to install X just to use a scripting language, then I feel that there is something wrong with the way it is being packaged. I don't like installing extra software cruft on my servers - it's just more software to monitor for local/remote exploits.

Anyway, I've stated my case and what I think is a good solution. There are workarounds for me such as the -d flag for pacman or rebuilding my package via abs (which I'm currently doing). I just feel that my point is valid and would love to see it adopted.

Cheers,
farphel

contrasutra · 2003-12-28 22:56:06

That's one of my peeves with this too. I consider Tk extra "crap". If I were to write a GUI using python, I would rather use pyGTK or pyQT (both of which are also platform independent). Of course this is a personal opinion.

Tk is cross platform too. IDLE works fine in Windows.

sarah31 · 2004-01-10 19:22:09

while i have long been for not creating multiple version of packages i think it is time this was reconsidered....at least for some packages. arch is getting well used now and user demands are changing.

Xentac · 2004-01-10 19:41:31

I didn't post my opinion last time but I will now. If I maintained python it would be split out.

sarah31 · 2004-01-10 19:45:33

thanks it is important to get developer input. it is fine to hold certain policies up but if even developers see that this is becoming a problem in some cases compromises are a good option.

zen guerilla made an excellent one for me this week with gift and sylpheed-claws.

Xentac · 2004-01-10 19:51:28

I'm on it... so hopefully I'll have something soon... this new keymap is definitely slowing me down.

Arch Linux

#1 2003-12-24 01:15:30

python without tk

#2 2003-12-24 02:14:02

Re: python without tk

#3 2003-12-24 12:09:44

Re: python without tk

#4 2003-12-27 21:47:30

Re: python without tk

#5 2003-12-27 22:23:28

Re: python without tk

#6 2003-12-27 22:52:09

Re: python without tk

#7 2003-12-28 01:14:30

Re: python without tk

#8 2003-12-28 02:02:19

Re: python without tk

#9 2003-12-28 13:46:01

Re: python without tk

#10 2003-12-28 22:56:06

Re: python without tk

#11 2004-01-10 19:22:09

Re: python without tk

#12 2004-01-10 19:41:31

Re: python without tk

#13 2004-01-10 19:45:33

Re: python without tk

#14 2004-01-10 19:51:28

Re: python without tk

Board footer