«

>>>> Terry Reedy writes:

>> To put it another way, needing a Python interpreter to run .py files is no
>> different from, for instance, needing a movie player to run .mpg files, and
>> all Windows users are or need to become familiar with that general concept.

The problem for windows users isn't that they have to download a movie
player to play .mpg files... it's that they also have to download and
install python/java runtime to "play" the player because it was written
in python/java. Most won't bother and will download/install native
win32 app instead.

Roger Binns schrieb:
> As far as I can tell, they failed at two hurdles. One is that there
> is a new BitPim release every two weeks and they can't really keep up
> with that. (eg it takes around two weeks for packages with a lot of
> attention on Gentoo to become stable and often is a lot longer)

This is why many open source projects include (possibly outdated) .spec
files directly in their tree. Makes it easy to just adapt them and run
rpmbuild. Similar for Debian package specs.

With Python sources it is even easier (most of the time) since you can run
python setup.py bdist_rpm
which spits out a readily baken RPM, ready to be nailed into the system.
Sadly, this doesn't exist for Debian and it doesn't work for all Python
packages (Twisted, that is).

Stefan

"Stefan Behnel" <> wrote in message news:d3vscb$i8r$...
>
> Roger Binns schrieb:
>> As far as I can tell, they failed at two hurdles. One is that there
>> is a new BitPim release every two weeks and they can't really keep up
>> with that. (eg it takes around two weeks for packages with a lot of
>> attention on Gentoo to become stable and often is a lot longer)
>
> This is why many open source projects include (possibly outdated) .spec files directly in their tree. Makes it easy to just adapt
> them and run rpmbuild. Similar for Debian package specs.

Funnily enough there is an ebuild file in the BitPim source. However
it has to be munged for each release since Gentoo requires the ebuild
filename to include the version number. I don't bother releasing that
file due to the onerous non-automated SourceForge file upload process.
(And many of the dependencies aren't in Portage anyway so this would
have to be quite a number of ebuilds).

> With Python sources it is even easier (most of the time) since you can run
> python setup.py bdist_rpm
> which spits out a readily baken RPM, ready to be nailed into the system. Sadly, this doesn't exist for Debian and it doesn't work
> for all Python packages (Twisted, that is).

The distutils approach is mainly useful for packages and libraries,
not for applications. And of course it still has the prerequisites
issues mentioned earlier.

Roger

Roger Binns napisa³(a):

> The distutils approach is mainly useful for packages and libraries,
> not for applications. And of course it still has the prerequisites
> issues mentioned earlier.

This reminds me, that there is still no clear direction as to where
install Python applications on Linux if one wants to be FHS-compliant.
Teoretically, one may try to install to /opt/appname hierarchy, but many
distributions simply refuse such packages (as it was the case with my
JPA in PLD Linux).

--
Jarek Zgoda
http://jpa.berlios.de/ | http://www.zgodowie.org/

Just to add my voice to those suffering because of this issue...

For me the main problem is going to a two step install. Also, it makes
my application much bigger.

Responding to earlier comments, you know what's really frustrating? So
far, every pc which has failed to install my app has actually had a
copy of this dll someplace. One is tempted to script the installer to
search for the thing and then copy it over. One wonders that the
install failure rate would be then. BUT, this would still be an
unacceptable risk. Nothing makes customers more angry than install
problems.

Bottom line: If MS wants to support an open source programming
language, they have to do more than give away a tool chain. They also
have to license their libraries in a compatible way.

Further, (well aware that as the recipeient of a free tool my
complaints might be properly dumped in the trash) if PDF wants to
distribute same, they need to ensure that users will be free to do
programming language type activities, like package and distribute
applications.

So I've got some time before I actually have to distribute, but I do
hope for a solution to this problem.

Thanks very much for all your hard work,

Sean Cavanagh

It would be *really* nice if it worked for Python itself for making an
RPM distribution of Python.