Ten Essential Development Practices

[Mike Meyer]

In practise any Python GUI is going to contain code from otyher
languages since if it was coded all the way down in python it would
be too slow.

Not necessarily. My window manger is Python all the way down - it uses
the Python Xlib implementation - and is plenty fast.

Of course, it doesn't do a lot of graphics work, even for a window
manager.

<mike

 

[Mike Meyer]

On Windows and Mac, you download the package and run through the wizard.

Which package? I'm looking at the sourceforge download site, and don't
see any packages for Python 2.4 on OS X 10.4. In fact, I don't see any
packages for 10.4 at all. IIRC, they didn't have a 2.4 package last
time I looked. I may download the 10.3 one and see if it works.

Admittedly, installing from source is more difficult than any other
project I've found, but still doable.

Well, I've got a long history of installing things from source - going
back to v6. On OS X, I like the darwin ports stuff, so I tried that:

% sudo port install wxpython

It blew up trying to compile wxpython. The multitude of dependencies
all seemed to build find. Building wxpython from the source
distribution by hand doesn't seem to fair any better.

Could be that it's 10.4 problem that hasn't been diagnosed yet.

We'll see if the FreeBSD port works any better.

<mike

P.S. - no, this isn't just a theoretical exercise. I want to play with
THE, and that's been rewritten from it's Mac-only version to use the
Python wxWidgets wrapper. It's mostly curiosity, so I'm not willing to
work very hard on it. If the dependencies will build out of the box -
cool. If not - I have lots of other things to do.

 

[Paul McNett]

Which package? I'm looking at the sourceforge download site, and don't
see any packages for Python 2.4 on OS X 10.4. In fact, I don't see any
packages for 10.4 at all. IIRC, they didn't have a 2.4 package last
time I looked. I may download the 10.3 one and see if it works.

I can confirm that the 10.3 one works on Tiger. I think that Robin
doesn't have a Tiger machine to build on yet, which is why there's no
package for it. Perhaps more information is at the wxPython download
site (not the Sourceforge one) at:

http://wxpython.org/download.php

Well, I've got a long history of installing things from source - going
back to v6. On OS X, I like the darwin ports stuff, so I tried that:

% sudo port install wxpython

It blew up trying to compile wxpython. The multitude of dependencies
all seemed to build find. Building wxpython from the source
distribution by hand doesn't seem to fair any better.

To build wxPython from source, you really need to follow Robin's
detailed instructions in BUILD.txt, located somewhere in the source tree
(I have to look for it every time, but I think it is in
wxSrc/wxPython/docs/BUILD.txt). It isn't difficult but there's more to
it than the standard ./configure;make;make install.

P.S. - no, this isn't just a theoretical exercise. I want to play with
THE, and that's been rewritten from it's Mac-only version to use the
Python wxWidgets wrapper. It's mostly curiosity, so I'm not willing to
work very hard on it. If the dependencies will build out of the box -
cool. If not - I have lots of other things to do.

I think you'll find that wxPython installs perfectly on Tiger using the
package provided. Indeed, the only really painful platform to install
wxPython on is Linux, where you pretty much need to build from source if
you want the latest and greatest.

 

[phil hunt]

Not necessarily. My window manger is Python all the way down

Your X server is written in Python?

- it uses
the Python Xlib implementation - and is plenty fast.

Of course, it doesn't do a lot of graphics work, even for a window
manager.

That's what I mean: painting the individual pixels on the screen.

 

[Torsten Bronger]

Hallöchen!

[...]

I'm interested in a language with a big community. This is my
definition of success. [...]

GUI applications seem to be the most attractive application type.
This is not only true for commercial programming. When I look at
the most agile projects on Sourceforge, almost all of them have a
GUI.

Why restrict yourself to agile projects?

Because such projects attract the greatest number of developers,
many of them being amongst the most diligent developers, too. I
expect this to have a positive influence of the language.

[...]

I won't argue that most of the projects on Sourceforge have GUIs -
that's certainly true. I will argue that most of the projects are
done in languages that aren't what you call GUI-aware.

Yes, this is what I meant with "legacy code". C and C++ are
actually special-purpose. They are good for controlling a computer
but not for implementing an idea. Their current vitality on almost
all software areas arise from the fact that they had been extremely
successful before Java, C#, and VB came into play. Invented today,
they would be niche languages.

However, even C++ is really successful only when used as a GUI-aware
dialect. Additionally, Python does not have this legacy bonus.

Since you haven't stated what that definition is, I can't really say
anything about this.

Yes, I did.

[...]

Legacy code is not a sign of success IMO because it implies a
difficult future.

So you're saying that Python, Perl, Linux, the various BSD
et. al. will have a difficult future? [...]

No. All I said was that if a language's "success" relies almost
exclusively on the heavy presence of legacy code, its future is
difficult. I see this for C and C++ excluding VC++. They will
always be there, but "cool new things" will be made available
firstly (or only) for Java, C#, Python etc.

[...]

Or maybe you could switch to Jython, and just use swing?

Actually I'm very happy with CPython. Besides, I don't like the
Java world. When I left C++ last winter, I dithered between C#,
Ruby, and Python.


BTW this thread was extremely interesting for me. I've learnt a
lot. (Unfortunately, two weeks ago I opted for wxPython, after a
long and tough time of thorough pondering, and today this thread
informed be about progress on the Tk front. *cry* ;-)

Tschö,
Torsten.

 

[Cliff Wells]

Yes, this is what I meant with "legacy code". C and C++ are
actually special-purpose. They are good for controlling a computer
but not for implementing an idea. Their current vitality on almost
all software areas arise from the fact that they had been extremely
successful before Java, C#, and VB came into play.

Unfortunately your assertion is patently false. C and C++ are very much
general-purpose languages. It is a logical contradiction to assert that
Java, C#, VB and Python are general-purpose languages while C and C++
are not when the former were implemented using the latter.
Being implemented in C, Python can do nothing that C cannot. It can
certainly make it *easier* to do things, but it conveys no new abilities
other than that of meeting deadlines

As an aside, I don't disagree with what I think is your main point:
higher-level abstractions make more advanced ideas feasible. You simply
state it far too strongly.

Regards,
Cliff

 

[Torsten Bronger]

Hallöchen!

Unfortunately your assertion is patently false. C and C++ are
very much general-purpose languages.

This is true in the sense that you can realise an arbitrary program
with them, and you can use the full power of the computer. But in
my opinion the era of such programming is over. Already today but
even more in the future programs of all kind are coded in the
higher-level languages (including VC++), limiting C(++) to the field
of system programming. Probably quibbling, but this is how I meant
it.

Tschö,
Torsten.

 

[Mike Meyer]

Yes, I've used it to bundle wxPython apps on 10.3.


OpenBSD: in portage
FreeBSD: in portage
386BSD: don't know... does anyone still use this?
NetBSD: included AFAICT
Fedora: rpms available
Debian: debs available
Ubuntu: included
Gentoo: in portage
OS/X: available on wxpython.org

Um - you're not answering the question I asked. I asked "What app do I
use to bundle my applications for Unix, ala py2exe (or whatever it is)
for Windows?" You're telling me how to install wxPython on those
platforms.

I know how to install wxPython. What I want to know is how to build an
application bundle for all those Unix systems for a Python app I use
that includes wxPython - or any other third party libraries I may be
using.

<mike

 

[Mike Meyer]

What works for you? You believe that chaos is better than having standards?
I believe that flexibility is good, but not chaos.

I believe that multiple competing options is better than an externally
enforced standard, or a single option with a near-monopoly position.

If none of the options are good enough for the job at hand, you create
your own.

One IDE, you mean? I believe the freedom to choose from multiple IDEs is
also good. Some code on VI, others on Emacs, others on Eclipse, others
on ...

IDE is short for "integrated development environment". I chose a
slightly broader phrase. The languages had more options than one
specific distribution, but that one dominated at least one market.

And does it integrate well with common business apps, such as a mail client,
note taking apps, addressbooks (with personal and shared entries), calendar
with ability to share appointments, etc.?

Of course.

<mike

 

[Mike Meyer]

Your X server is written in Python?

I see the smiley, but just to make sure no one is confused, the answer
is no. My window manager is written in Python. Unlike monolithic
programs in proprietary OS's, X seperates the window manager from the
thing that actually paints pixels on the screen. It's possible to run
the window manager on another computer entirely, and people used to
sell boxes that ran in that configuration out of the box.

That's what I mean: painting the individual pixels on the screen.

Well, no X graphics package will get any closer to that than my python
window manager. The python code sends packets to the X server, and
parses what comes back from it.

<mike

 

[Mike Meyer]

Hallöchen!

[...]
I'm interested in a language with a big community. This is my
definition of success. [...]

GUI applications seem to be the most attractive application type.
This is not only true for commercial programming. When I look at
the most agile projects on Sourceforge, almost all of them have a
GUI.

Why restrict yourself to agile projects?

Because such projects attract the greatest number of developers,
many of them being amongst the most diligent developers, too. I
expect this to have a positive influence of the language.

You didn't answer the question about how you define agile
project. Please do so if you expect a comment on this.

Yes, this is what I meant with "legacy code". C and C++ are
actually special-purpose. They are good for controlling a computer
but not for implementing an idea. Their current vitality on almost
all software areas arise from the fact that they had been extremely
successful before Java, C#, and VB came into play. Invented today,
they would be niche languages.

This is patently absurd. C and C++ were born as general-purpose
languages. Changing the environment around them isn't going to change
that.

However, even C++ is really successful only when used as a GUI-aware
dialect. Additionally, Python does not have this legacy bonus.

The only dialect that might be considered "GUI-aware" is C#. Or maybe
you mean they're only succesfull when coupled with a GUI library? I'd
say that's due to your warped definition of success, and I'm not going
to argue with your definition.

Yes, I did.

No, you agreed with my definition, with the proviso that you had to
consider how "important" the application area was. Which leaves it
undefined.

Legacy code is not a sign of success IMO because it implies a
difficult future.

So you're saying that Python, Perl, Linux, the various BSD
et. al. will have a difficult future? [...]

No. All I said was that if a language's "success" relies almost
exclusively on the heavy presence of legacy code, its future is
difficult. I see this for C and C++ excluding VC++.

Well, you lumped all C/C++ code a legacy code. The most successful
distribution of Python is the one written in C, so it's success relies
almost exclusively on legacy code. Ditto for Perl, Linux, etc.

You can't have it both ways. Either C/C++ is all legacy code, or it's
not. If it is, the building products in Python/Perl/Java (and probably
most of the others) is building in a dependence on a legacy code base.

If they *aren't* legacy code, then your premise that C/C++ only has
legacy code is false. Personally, I think your premise is false. There
are lots of projects still under active development using C/C++. There
are new ones starting every day. Contrary to your assertion about
VC++, they are starting in environments where VC++ doesn't run.

I think you need to come out from behind your Windows box for a
while. There are *lots* of applications areas that don't need GUIs,
and don't run on Windows. I'll bet most of the computers in your house
are running software that falls into that category.

<mike

 

[Mike Meyer]

To build wxPython from source, you really need to follow Robin's
detailed instructions in BUILD.txt, located somewhere in the source
tree (I have to look for it every time, but I think it is in
wxSrc/wxPython/docs/BUILD.txt). It isn't difficult but there's more to
it than the standard ./configure;make;make install.

I found BUILD.txt. I followed it to the letter. It still blew
up. There may be a problem with Tiger that hasn't been reported yet
(yeah, I know - I really ought to report it...).

Then again, it could be a problem with trying to install it on the
darwin ports Python 2.4 package instead of the 2.3.5 that Tiger ships
with.

I think you'll find that wxPython installs perfectly on Tiger using
the package provided. Indeed, the only really painful platform to
install wxPython on is Linux, where you pretty much need to build from
source if you want the latest and greatest.

Well, it built just fine on my FreeBSD box. Then again, I've generally
found installing from source on FreeBSD to be easier than installing
RPM's on Linux. I'll probably copy THE over to my FreeBSD box and try
it there.

thanks,
<mike

 

[Cliff Wells]

Um - you're not answering the question I asked. I asked "What app do I
use to bundle my applications for Unix, ala py2exe (or whatever it is)
for Windows?" You're telling me how to install wxPython on those
platforms.
I know how to install wxPython. What I want to know is how to build an
application bundle for all those Unix systems for a Python app I use
that includes wxPython - or any other third party libraries I may be
using.

Sorry, I assumed you'd know about distutils:

http://www.python.org/doc/current/dist/
http://www.python.org/doc/current/dist/built-dist.html

distutils can go so far as to build an rpm for you, but you'll need to
package things like .debs yourself.

Cliff

 

[Torsten Bronger]

Hallöchen!

[...]

Because such projects attract the greatest number of developers,
many of them being amongst the most diligent developers, too. I
expect this to have a positive influence of the language.

You didn't answer the question about how you define agile
project. Please do so if you expect a comment on this.

Projects with a high Sourceforge activity index.

[...]

Yes, this is what I meant with "legacy code". C and C++ are
actually special-purpose. They are good for controlling a
computer but not for implementing an idea. Their current
vitality on almost all software areas arise from the fact that
they had been extremely successful before Java, C#, and VB came
into play. Invented today, they would be niche languages.

This is patently absurd. C and C++ were born as general-purpose
languages. Changing the environment around them isn't going to
change that.

In 1955 people would have told you that Fortran is general-purpose.
It's not the case any more.

[...]

Legacy code is not a sign of success IMO because it implies a
difficult future.

So you're saying that Python, Perl, Linux, the various BSD
et. al. will have a difficult future? [...]

No. All I said was that if a language's "success" relies almost
exclusively on the heavy presence of legacy code, its future is
difficult. I see this for C and C++ excluding VC++.

Well, you lumped all C/C++ code a legacy code.

No because ...

[...]

You can't have it both ways. Either C/C++ is all legacy code, or
it's not.

.... is wrong in my opinion. Why should this be?

[...]

I think you need to come out from behind your Windows box for a
while.

But you did read my headers? ;-)

There are *lots* of applications areas that don't need GUIs,
and don't run on Windows.

This becomes a discussion about estimates we both don't know
exactly, and weight differently, so I'll leave it here.

Tschö,
Torsten.

 

[Mike Meyer]

Sorry, I assumed you'd know about distutils:

Cliff, please quit being an ass. You keep assuming that because some
tool isn't the answer to my question that I don't know about
it. That's simply rude. It would be *much* more polite to ask "What's
wrong with distutils" rather than saying "So you don't know about
distutils."

http://www.python.org/doc/current/dist/
http://www.python.org/doc/current/dist/built-dist.html

distutils can go so far as to build an rpm for you, but you'll need to
package things like .debs yourself.

I've very familiar with distutils. It doesn't do what I asked for, in
that it only bundles up *my* code. It doesn't bundle the things I
depend on the way py2exe does. It's patently *not* the answer to the
question I asked.

For those who want .deb's out of distutils, there's a PR on
sourceforge that includes a patch to make it generate .debs that works
quite well.

Of course, anyone who built a .deb (or an RPM, or a port, or whatever)
that bundled up everything it needed would be doing *the wrong
thing*. Those formats are designed for packaging single distributions,
not applications. They include dependency information that is used to
fetch the dependencies and install them. From my standpoint, the
problem here is that you then have to get the dependencies into the
repository before you can put your application there and have it
work. For instance, my port of bicyclerepairman is stuck at an old
version because I haven't gotten a port PyMac accepted yet (it also
has to do with bugs in the xemacs port, but that's another story).

I'm surprised you haven't mentioned eggs yet. Those work across all
the platforms I named. Of course, they aren't the answer to my
question either, because, like PRMs et al, they only reference
external dependencies, they don't include them.


<mike

 

[Dennis Lee Bieber]

In 1955 people would have told you that Fortran is general-purpose.
It's not the case any more.

You didn't work for my previous program... I think we stopped
short of coding an X-client in it (too "legacy" based, still had some
F-IV code that was being migrated to F-77.... F90's dynamic memory might
have allowed the X-client work).

--

 

[Cliff Wells]

Cliff, please quit being an ass. You keep assuming that because some
tool isn't the answer to my question that I don't know about
it. That's simply rude. It would be *much* more polite to ask "What's
wrong with distutils" rather than saying "So you don't know about
distutils."

Since you said "please". I'll try to forget about "the wonders of X"
comment you made that I found just as rude.

I've very familiar with distutils. It doesn't do what I asked for, in
that it only bundles up *my* code. It doesn't bundle the things I
depend on the way py2exe does. It's patently *not* the answer to the
question I asked.

It can. It isn't terrifically easy, but distutils can be used to
package up 3rd party libraries, including binary libs. It can, in fact,
package up any file you so desire.

For those who want .deb's out of distutils, there's a PR on
sourceforge that includes a patch to make it generate .debs that works
quite well.

I wasn't aware of that. Nice.

Of course, anyone who built a .deb (or an RPM, or a port, or whatever)
that bundled up everything it needed would be doing *the wrong
thing*. Those formats are designed for packaging single distributions,
not applications. They include dependency information that is used to
fetch the dependencies and install them. From my standpoint, the
problem here is that you then have to get the dependencies into the
repository before you can put your application there and have it
work. For instance, my port of bicyclerepairman is stuck at an old
version because I haven't gotten a port PyMac accepted yet (it also
has to do with bugs in the xemacs port, but that's another story).

I'm surprised you haven't mentioned eggs yet. Those work across all
the platforms I named. Of course, they aren't the answer to my
question either, because, like PRMs et al, they only reference
external dependencies, they don't include them.

While this describes the general use case of RPM, you can most certainly
include external dependencies. You do it by not making them external.
If you need wxPython included with your app, you can build wxPython as a
subtree of your project and package it that way. While wasteful of
space, it is also the only sure way to make sure that your app has the
correct version and all needed dependencies. This is how py2exe does it
on Windows and py2app does it on Mac (they just make it automatic).

People find Linux more difficult to distribute binary apps on because
they try to follow the typical Linux pattern for distributing packages
versus using the one used elsewhere. For binaries this doesn't work
very well.

Cliff

 

[Mike Meyer]

Hallöchen!

Projects with a high Sourceforge activity index.

That doesn't seem to match the common defintion of "agile" when it
comes to programming. Then again, you have a habit of using words to
mean whatever you want, without much reference to how they're used by
the rest of the industry.

In 1955 people would have told you that Fortran is general-purpose.
It's not the case any more.

Sorry, but you're wrong. FORTRAN is very much a general purpose
language. Modern version don't resemble the version from 1955 very
much, but that's true for most languages that are that old.

Legacy code is not a sign of success IMO because it implies a
difficult future.
So you're saying that Python, Perl, Linux, the various BSD
et. al. will have a difficult future? [...]
No. All I said was that if a language's "success" relies almost
exclusively on the heavy presence of legacy code, its future is
difficult. I see this for C and C++ excluding VC++.

Well, you lumped all C/C++ code a legacy code.

No because ...

Yes, you did do that. I objected to you doing that, because it isn't
so.

... is wrong in my opinion. Why should this be?

Because any given proposition is either true or false. The truth may
not be know (or even knowable), but the proposition is still either
true or false.

This becomes a discussion about estimates we both don't know
exactly, and weight differently, so I'll leave it here.

No, it's not a discussion about estimates. The average household in
a G8 country has more computers that don't run Windows - and in fact
don't have GUIs at all - than otherwise. This is a fact of life.

<mike

 

[Mike Meyer]

Since you said "please". I'll try to forget about "the wonders of X"
comment you made that I found just as rude.

I made one comment that you found rude - which wasn't intended to be -
and you feel that's justification for intentionally insulting me in
pretty much every reply?

It can. It isn't terrifically easy, but distutils can be used to
package up 3rd party libraries, including binary libs. It can, in fact,
package up any file you so desire.

So can tar. That doesn't make it a solution to the problem, either.

While this describes the general use case of RPM, you can most certainly
include external dependencies. You do it by not making them external.
If you need wxPython included with your app, you can build wxPython as a
subtree of your project and package it that way. While wasteful of
space, it is also the only sure way to make sure that your app has the
correct version and all needed dependencies. This is how py2exe does it
on Windows and py2app does it on Mac (they just make it automatic).

Right. Let's go back to the original question: What's the app I use on
Unix that acts like py2exe on Windows and py2app on Unix?

Any archiving system can be coerced into collecting all the parts
together. None of them do it automatically. That automatically makes
them *not* an answer to the question.

<mike

 

[Mike Meyer]

FWIW, Tiger ships with wxPython pre-installed.

<mike