Re: Python 2.4 killing commercial Windows Python development ?
Thomas Heller
> I've been using python to write a simple 'launcher' for one of our
> Java applications for quite a while now. I recently updated it to use
> python 2.4, and all seemed well.
>
> Today, one of my colleagues noted that on her machine the launcher
> would complain it was missing a DLL - msvcr71.dll
>
> However, there's a very grey area concerning the redistribution of said DLL.
>
> If you've been keeping up with the dev list, and some other web
> discussions, you'll see that this has cropped up several times, but
> with no conclusion in a legal fashion other than 'investigate it on
> your own legal terms'.
>
> I'm now going to have step back to using 2.3 until this issue is
> solved, but judging by the way the dev list discussion just faded, I
> get the impression that it may be a long wait.
>
> I can't see how any company (or individual) can distribute an
> application written in python, and then 'frozen' (I used py2exe) in
> any way if they rely on the python24.dll that ships as standard. This
> is surely a step backwards in usability.
For commercial development, it should not be a problem to buy a license
for MSVC 7.1, which gives you the right to distribute msvcrt71.dll.
And maybe that's the reason that few people care about this issue?
Thomas
Michael Kearns
applications for quite a while now. I recently updated it to use python
2.4, and all seemed well.
Today, one of my colleagues noted that on her machine the launcher would
complain it was missing a DLL - msvcr71.dll
However, there's a very grey area concerning the redistribution of said DLL.
If you've been keeping up with the dev list, and some other web
discussions, you'll see that this has cropped up several times, but with
no conclusion in a legal fashion other than 'investigate it on your own
legal terms'.
I'm now going to have step back to using 2.3 until this issue is solved,
but judging by the way the dev list discussion just faded, I get the
impression that it may be a long wait.
I can't see how any company (or individual) can distribute an
application written in python, and then 'frozen' (I used py2exe) in any
way if they rely on the python24.dll that ships as standard. This is
surely a step backwards in usability.
I have no idea concerning the issues of rebuilding a different version
of python24.dll to be linked against the common msvcr.dll or whatever,
or changing the 'freeze' applications to do some magic, but I can't
believe it should be down to the end user to jump through legal or
compilation hoops when they're trying to use the language.
Apologies if this seems more aggressive than I intended it to be - I'm
just frustrated at having to stop following my language of choice for
the foreseeable future so far as my work is concerned.
Michael.
Michael Kearns
> For commercial development, it should not be a problem to buy a license
> for MSVC 7.1, which gives you the right to distribute msvcrt71.dll.
>
> And maybe that's the reason that few people care about this issue?
Hi Thomas,
There are a few problems with this as I see it. In theory, the 'cost' of
MSVC 7.1 shouldn't be a problem for a big organisation. However, I
wouldn't expect to have to go and buy it purely because I'm developing
(perhaps) a shareware application using python - this isn't my case, but
I wasn't looking at it from just a big organisation perspective.
Also, I don't believe that just 'owning' MSVC 7.1 is enough. From
cursory glances at the various redist files, I would also have to ship
the EULA, and as an end-user (of python) I can't just redistribute the
files - perhaps I could write a place holder application in MSVC to
suggest that I was no longer an end-user, but this seems ridiculous as a
workaround.
There even seem to be 'exclude' clauses to redistribution concerning
open-source material, but IANAL and ran from the various paragraphs.
I would like to think that python would encourage as many folk as
possible to use the language wherever it fits best (and perhaps even
beyond) and yet this is going in the opposite direction.
Would it be so difficult for a 'no legalese attached' version to be
provided on windows, or at the very least, some kind of statement
regarding what is and isn't allowed ? There seems nothing within the
python distribution stating the redistribution rights of the dll
(correct me if I'm wrong) which already seems contrary to the MS
requirements.
As much as I'd like to continue using it, because of the vague legal
situation, I can't, and that's unfortunate.
Michael.
Tim Peters
> ...
> Also, I don't believe that just 'owning' MSVC 7.1 is enough. From
> cursory glances at the various redist files, I would also have to ship
> the EULA, and as an end-user (of python) I can't just redistribute the
> files - perhaps I could write a place holder application in MSVC to
> suggest that I was no longer an end-user, but this seems ridiculous as a
> workaround.
>
> There even seem to be 'exclude' clauses to redistribution concerning
> open-source material, but IANAL and ran from the various paragraphs.
>
> I would like to think that python would encourage as many folk as
> possible to use the language wherever it fits best (and perhaps even
> beyond) and yet this is going in the opposite direction.
>
> Would it be so difficult for a 'no legalese attached' version to be
> provided on windows, or at the very least, some kind of statement
> regarding what is and isn't allowed ?
I think it would be difficult. "We" (the Python developers) didn't
write Microsoft's license, have no special insight wrt it, and aren't
lawyers either. If you want legally binding clarifications or
exemptions, I think they have to come from Microsoft (it's their
license).
It would be cool if commercial users got together, pursued this with
MS, and shared what they learned. Of course it would also be cool if
someone with no commercial MS interests did so, but the chance of that
happening seems nil.
> There seems nothing within the python distribution stating the redistribution
> rights of the dll (correct me if I'm wrong) which already seems contrary to the
> MS requirements.
That's possible too. MS hasn't complained to the PSF yet, but that's
no guarantee they won't.
> As much as I'd like to continue using it, because of the vague legal
> situation, I can't, and that's unfortunate.
Maybe the Python Business Forum could take this on? I don't know
whether they're still active, and their site isn't working today (at
least not for me):
http://www.python-in-business.org/
If someone(s) volunteered to do the work, it's also possible (not
certain) that the PSF would pay for lawyer time.
Nemesis
> I've been using python to write a simple 'launcher' for one of our Java
> applications for quite a while now. I recently updated it to use python
> 2.4, and all seemed well.
> Today, one of my colleagues noted that on her machine the launcher would
> complain it was missing a DLL - msvcr71.dll
I have the same problem. But I have a doubt, does Python installer ship
this dll?
What happens if I try to install Python2.4 on a system wich doesn't have
the dll?
--
The complete lack of evidence is the surest sign that the conspiracy is
working.
|\ | |HomePage : http://nem01.altervista.org
| \|emesis |XPN (my nr): http://xpn.altervista.org
Do Re Mi chel La Si Do
This DLL come also with MS-JVM engine, who is free. Therefore...
--
Michel Claveau
"Martin v. Löwis"
> I have the same problem. But I have a doubt, does Python installer ship
> this dll?
It sure does.
> What happens if I try to install Python2.4 on a system wich doesn't have
> the dll?
It will just work. Python installs the DLL if it is missing, and leaves
it alone (just incrementing the refcount) if it is present on the target
system.
Regards,
Martin
"Martin v. Löwis"
> There are a few problems with this as I see it. In theory, the 'cost' of
> MSVC 7.1 shouldn't be a problem for a big organisation. However, I
> wouldn't expect to have to go and buy it purely because I'm developing
> (perhaps) a shareware application using python - this isn't my case, but
> I wasn't looking at it from just a big organisation perspective.
For developers that need msvcr71.dll on the target system which don't
have a license to distribute it, the solution is simple: they just need
to advise their users to install python-2.4.1.msi. This comes with
msvcr71.dll included.
Regards,
Martin
Tony Meyer
One option is to create a Windows Python 2.4 installer that includes a
Python not built with MSVC7 - for example gcc or MSVC6 - which doesn't have
the dependency on mscvr71.dll. Both VC6 and gcc are feasible, although
there may be a reasonable amount of work required.
If the installer proved popular, then I'm sure the python-dev people could
be convinced (for 2.5, perhaps) that there should be an official release of
this type, much like there's a separate 64 bit installer available.
(Assuming that patches could be submitted that made the build process as
seamless as the existing one).
This seems a much more achievable goal than anything involving a meeting
with Microsoft...
=Tony.Meyer
A.B., Khalid
Kindly note that the Python source distribution does include project
files for building Python 2.4 with MSVC6. Add to that the fact that
with pyMinGW[1] one can build yet another Windows distribution not
dependent on mscvr71.dll and some of the logic about not upgrading to
Python 2.4, IMHO, just goes away.
An official release of installers for either or both versions would I
think complicate matters: more choices translate to more confusion.
Needless to say that extension authors (for Python 2.4) would then need
to make two binaries for every extension they release for Python 2.4:
one for the mscvr71.dll dependent Python distribution, and another one
for the mscvrt.dll dependent version(s). This I think would hurt Python
and its users.
The solution is to have those that know enough to really need to build
Python on their own according to their requirments. They would then
have to deal with compiling the Python 2.4 extensions themselves, of
course. But this would make things simple and hopefully address the
needs of everyone.
Regards,
Khalid
[1] pyMinGW:
http://jove.prohosting.com/iwave/ipython/pyMinGW.html
Peter Hansen
I believe there are no restrictions on us redistributing
python-2.4.1.msi either, which would suggest that it
could simply be included in an installer package, and
perhaps the relevant DLLs could even be extracted from
the msi file without having to install it... I seem
to recall someone ;-) was making progress on an msi
package for Python which might be capable of this
too.
Of course then you'd need Python installed already in
order to install your application. On the other hand,
you could always include a copy of Python 2.3 as well,
and use that to extract the DLLs from the MSI.
Or other equally insane approaches ...
-Peter
Do Re Mi chel La Si Do
Michael Kearns
> For developers that need msvcr71.dll on the target system which don't
> have a license to distribute it, the solution is simple: they just need
> to advise their users to install python-2.4.1.msi. This comes with
> msvcr71.dll included.
I understand this, and it's obviously a solution. Unfortunately it
defeats the whole point of me 'freezing' my code in the first place.
The main feature (for me) of the way I could use this, was to create a
simple Java launcher that didn't require the user to install anything
extra, or end up with a whole stack of unused data on their machine.
They would see a .exe file, a dll and a pyd, and then the actual
application files, and that was it. It may be fine for a 'knowledgeable'
user to install python etc., but not for everyone.
Michael.
Michael Kearns
> Hi !
>
> This DLL come also with MS-JVM engine, who is free. Therefore...
>
This is very true (and the .NET suggestion as well). However, why should
I require an end-user to install MS-JVM or the .NET framework, purely
for a simple little launcher application ?
The main application it launches is Java, but there's no way it would
run on the MS-JVM, and .NET just gives a load more technology that we
don't really need (and is a bigger install than the entire application).
Michael.
Michael Kearns
> Kindly note that the Python source distribution does include project
> files for building Python 2.4 with MSVC6. Add to that the fact that
> with pyMinGW[1] one can build yet another Windows distribution not
> dependent on mscvr71.dll and some of the logic about not upgrading to
> Python 2.4, IMHO, just goes away.
>
> An official release of installers for either or both versions would I
> think complicate matters: more choices translate to more confusion.
> Needless to say that extension authors (for Python 2.4) would then need
> to make two binaries for every extension they release for Python 2.4:
> one for the mscvr71.dll dependent Python distribution, and another one
> for the mscvrt.dll dependent version(s). This I think would hurt Python
> and its users.
>
> The solution is to have those that know enough to really need to build
> Python on their own according to their requirments. They would then
> have to deal with compiling the Python 2.4 extensions themselves, of
> course. But this would make things simple and hopefully address the
> needs of everyone.
This is all very true, and a fair point of what is achievable. It just
seems unfortunate that a developer is required to get involved in C
compilation and looking after all module dependencies, purely to use
Python in a commercial environment.
I write Java as my main language. It's what I'm paid to do, and I've
spent the best part of the last 8 years doing so.
Over the last couple of years, I've been toying with Python, and trying
to find ways to integrate it with my daily routine - I now have a
complete internal build system written with it, along with several
utility scripts.
I don't code C. I could probably blag it at a very slow pace, but I'm
not going to be given time to play with it. We have some C developers,
but again, no resource allocation will ever be made to compile a
language that isn't used for the mainstream software we produce.
All I'm trying to do is use python wherever I can without having to
persuade those in power that it would be a valuable asset (as this would
probably be a waste of breath in many circumstances), and yet I can't
(from 2.4 at least) because it requires more time and cost to be allocated.
I would guess from the responses so far that Python 2.4 just isn't used
within commercially shipping products, or is quietly used by an product
so as not to incur any legal wrath that might be found. Perhaps it isn't
quite ready for what I want to achieve. I don't know.
I just know that I am spending the rest of the day migrating back to 2.3
where I will stay.
Michael.
Robin Becker
.....
> I would guess from the responses so far that Python 2.4 just isn't used
> within commercially shipping products, or is quietly used by an product
> so as not to incur any legal wrath that might be found. Perhaps it isn't
> quite ready for what I want to achieve. I don't know.
>
> I just know that I am spending the rest of the day migrating back to 2.3
> where I will stay.
The switch to 2.4+msvc7.1 has been a success for MS as many developers now
require both 6 & 7 to provide full coverage. Of course this wasn't a pythonic
choice, but MS certainly encouraged the move by delivering free SDKs to key
people. It's not really MS's fault; they want to advance and get revenue like
everyone else; python has to follow or end up on a dying platform.
People have mentioned the older v6 build scripts/tools still work. Last time I
tried they seemed a bit out of date.
-wondering where my paper tape editor is-ly yrs-
Robin Becker
Fredrik Lundh
> I would guess from the responses so far that Python 2.4 just isn't used within commercially
> shipping products
that kind of unfounded hyperbole only makes you look silly.
> I don't know.
exactly. now calm down, and go read the replies to this thread again. or consult
a lawyer, and make it clear to him that you're not actually *using* the MSVCR71
component yourself, *and* that the Python application you are using (and passing
on to your users) is adding significant and primary functionality to the MSCVR71
library.
</F>
Fredrik Lundh
>> What happens if I try to install Python2.4 on a system wich doesn't have
>> the dll?
>
> It will just work. Python installs the DLL if it is missing, and leaves
> it alone (just incrementing the refcount) if it is present on the target
> system.
installs it where? the MS docs seem to indicate that they want you to install
it in the program directory, rather than in a "shared" location:
http://support.microsoft.com/default.aspx?scid=kb;en-us;326922
</F>
Michael Kearns
> Michael Kearns wrote:
>>I would guess from the responses so far that Python 2.4 just isn't used within commercially
>>shipping products
>
> that kind of unfounded hyperbole only makes you look silly.
As no-one had replied that they had found it fine to use in a commercial
sense, or pointed to other product that may use it, I'm not entirely
sure how it makes me look any sillier than I normally do in real life.
>>I don't know.
>
> exactly. now calm down, and go read the replies to this thread again. or consult
> a lawyer, and make it clear to him that you're not actually *using* the MSVCR71
> component yourself, *and* that the Python application you are using (and passing
> on to your users) is adding significant and primary functionality to the MSCVR71
> library.
I apologise if my writing suggests a lack of calm. I have fully read the
replies, and although there are many fine suggestions of shipping
additional products, none seems to address the lack of legality
regarding the windows distribution other than "It's not the Python
developers problem". Again, if I paraphrased incorrectly, I'm sorry.
As for consulting a lawyer, this is exactly what I'm trying to avoid. My
usage of python in a commercial sense is as a small utility - a helper,
if you will. It has no business value whatsoever, compared to the
product that it ships with, and certainly does not warrant any
investment regarding legal advice.
I would agree that Python is adding significant value to the library.
Unfortunately, the Microsoft Redistribution document, from what I read,
does not allow an end-user to further redistribute the library. I am
that end-user, of Python.
The whole situation is already becoming far more work than if I'd used a
different technology for what I had to achieve, and as such I have no
desire to pursue it further. I'm once more running 2.3, and happy with that.
With respect,
Michael.
Fredrik Lundh
> As for consulting a lawyer, this is exactly what I'm trying to avoid. My usage of python in a
> commercial sense is as a small utility - a helper, if you will. It has no business value
> whatsoever, compared to the product that it ships with, and certainly does not warrant any
> investment regarding legal advice.
without consulting a lawyer, how come you're so sure that the MS C support
library is the only component you're using that may cause you legal problems?
> Unfortunately, the Microsoft Redistribution document, from what I read, does not allow an end-user
> to further redistribute the library.
the REDIST document doesn't say anything like that, and neither does the
EULA (at least not the copies I have in my properly licensed VS Enterprise
installation).
all it says is that when the Python developers ("you" in the EULA) redistributes
the redistributable component as part of a Python distribution (the "licensee soft-
ware" in the EULA), the developers must respect the original EULA wrt. this
component. And when someone using Python is redistributing Python, that third
part ("your distributors" in the EULA) must also respect the original EULA wrt.
this component.
(see section 3.1a in the EULA, and make sure you understand what the words
"you", "licensee software", "redistributables" and "distributors" mean in that text)
</F>
Jeff Epler
seems to me that there today only a few technical problems remaining
with Python when built with mingw32.
If one of the people who has expressed such deep concern about this
"msvcr71.dll" problem would simply install the Free tools and start
putting patches on sourceforge, it's quite possible that for the next
2.4.x release the mingw32 "port" could be a first-rate one, and suitable
for the uses that the posters in this thread have mentioned.
Since mingw32 is Free (gpl and other licenses for tools, public domain
libraries and copyrighted headers with "no restrictions for programs"
built using the headers) anyone can install and use these tools and
mingw creates no new problems with distribution of the resulting binary,
whether the final product is Free or proprietary.
(Admittedly I don't know anything about whether "win32all" builds under
mingw32, and it's not clear whether binary compatibility with extensions
built by microsoft compilers is an easy goal either)
Jeff
Terry Reedy
"Michael Kearns" <michael...@REMOVEsaaconsultants.com> wrote in message
news:425b8948$0$38045$bed6...@news.gradwell.net...
>I understand this, and it's obviously a solution. Unfortunately it defeats
>the whole point of me 'freezing' my code in the first place.
>The main feature (for me) of the way I could use this, was to create a
>simple Java launcher that didn't require the user to install anything
>extra, or end up with a whole stack of unused data on their machine.
I guess I don't understand some people's determination to not have users
install fully useable Python on their Windows machines. Doing so seems no
different to me than having to install (or upgrade) Shockwave, or Apple's
Quicksomething for Windows (not used so much anymore), or RealPlayer, or
the lastest upgrade for DirectX, or DivX, or a zip decoder, or any other
3rd party software, to run .xxx files or specialized .exe programs. (And I
left out the most direct analogy of a java system.)
In other words, it seems to me that most Windows users should be familiar
with the idea of having to install a player or platform to run something
built on top of that player or platform. Bundling a private Python
interpreter with every Python script is much like bundling a private
Shockwave player with every Schockwave script. I think most people would
prefer having one copy of each.
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.
Also, I think it a bit 'anti-social' to hide usage of Python. If all
Python Windows programs ran with a normal, communally installed Python,
then users would gradually get the idea that having Python installed is
much like having Shockwave and other utility platforms installed, and that
is is part of a 'fully loaded' Windows system to have a .py player
installed.
If there is something about the default install of Python on Windows that
makes it less desireable or less easy than other platforms, then maybe that
can be fixed. To make installation easier, maybe someone could write a
small .exe that could be frozen with scripts or run with installers and
that would detect the presence/absence of the needed Python version and
offer an auto download and install if needed.
At least one thing in Python's favor is the lack of having to 'register'
before downloading (or after installation) and the ability to redistribute
the installer free and without special license.
Terry J. Reedy
Thomas Heller
[...]
> Also, I think it a bit 'anti-social' to hide usage of Python. If all
> Python Windows programs ran with a normal, communally installed Python,
> then users would gradually get the idea that having Python installed is
> much like having Shockwave and other utility platforms installed, and that
> is is part of a 'fully loaded' Windows system to have a .py player
> installed.
Isn't it a bit harsh to call this 'anti-social'?
>
> If there is something about the default install of Python on Windows that
> makes it less desireable or less easy than other platforms, then maybe that
> can be fixed. To make installation easier, maybe someone could write a
> small .exe that could be frozen with scripts or run with installers and
> that would detect the presence/absence of the needed Python version and
> offer an auto download and install if needed.
Sure. Someone.
>
> At least one thing in Python's favor is the lack of having to 'register'
> before downloading (or after installation) and the ability to redistribute
> the installer free and without special license.
Thomas
Dave Brueck
> I guess I don't understand some people's determination to not have users
> install fully useable Python on their Windows machines.
> 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.
>
> Python Windows programs ran with a normal, communally installed Python,
> then users would gradually get the idea that having Python installed is
> much like having Shockwave and other utility platforms installed, and that
> is is part of a 'fully loaded' Windows system to have a .py player
> installed.
>
> makes it less desireable or less easy than other platforms, then maybe that
> can be fixed. To make installation easier, maybe someone could write a
> small .exe that could be frozen with scripts or run with installers and
> that would detect the presence/absence of the needed Python version and
> offer an auto download and install if needed.
I mostly agree with the sentiment, but it does break down a little in practice.
At least currently it does - like you said, this is fixable, but nobody has
signed up to fix it yet.
The main thing that's needed is a zero-input Python distribution - a Python
runtime, if you will - that (1) gets installed to a "good" place (2) does so
without asking the user to do anything, (3) can coexist with different versions
of the runtime, and (4) is easily detectable by applications wanting to use it.
One other minor component is a small launcher executable, because on Windows
it's non-trivial to find out which "python.exe" in the task manager is running
which Python script. Anyway, each app would have a small launcher that
bootstraps the actual Python script[1]. (Or, if there's some way to trick the
task manager into displaying something besides "python.exe", that'd work too)
In order to "fit" into the expectations of a typical Windows user, an
application installer needs the ability to check for the presence of a
particular version of the Python runtime, and then install it if it's not
present, and do so without asking the user to do anything.
With that much in place, a lot of the need for freezing Python apps goes away
(definitely not all of it, but a lot of it). Here's stuff that still needs to be
considered though:
1) A way for apps to specify their compatibility with different versions of the
runtime - "I work with pyrt2.3.3 through 2.4.1"
2) A way for apps to register their dependency on that runtime, so that if the
user uninstalls it, there is at least an indication of what programs might break.
3) (this is a nice-to-have, but not 100% required) A way to download additional
libraries once and use them for multiple programs, e.g. the installer could see
if ctypes is present, and if not, go get it. Later programs would take advantage
of it already being installed. Like I said, not a 100% requirement, and some of
the ongoing work with code CPAN-like code repositories would shoehorn into this.
4) The security implications, e.g. an innocent app installs pywin32 and enables
Python client-side scripting in Internet Explorer, and later this is used as a
big door for malicious users to use.
Most of these tasks don't require a lot of work; indeed this has been on my "one
of these days" lists for awhile. The main reasons it hasn't been done yet:
1) The code freezing tools like py2exe are *very* good and convenient
(especially since loading code from zip archives was added - even if you include
all of Python, it's only a few files on disk, and now they're all in the same
directory)
2) Storage space and download speeds continue to increase at a rate much faster
than the rate at which the size of Python is growing - a download of a few MB
isn't too bad these days, who cares if your app takes 4MB on disk, and so what
if it doesn't fit on a floppy, for example.
3) As soon as you get started on such a project, almost immediately you will be
overwhelmed with a desire to create a CPAN-like system while you're at it, at
which point your project's status will shift from "making good progress!" to "in
quagmire, developers MIA". :)
-Dave
[1] I built a hacky one of these launcher exe's for one project, and it was
fairly reusable for apps in the same vein. Basically, the exe would would look
to see what its name was, and then load a Python module of the same name. So if
you have MyGame.py, you'd just take the generic launcher.exe, copy it to the
same directory as your .py files, and rename it to MyGame.exe. On launch, it'd
load the interpreter, load MyGame.py, and pass it the command-line args.
Thomas Heller
> Terry Reedy wrote:
>> If there is something about the default install of Python on Windows
>> that makes it less desireable or less easy than other platforms,
>> then maybe that can be fixed. To make installation easier, maybe
>> someone could write a small .exe that could be frozen with scripts
>> or run with installers and that would detect the presence/absence of
>> the needed Python version and offer an auto download and install if
>> needed.
>
> I mostly agree with the sentiment, but it does break down a little in
> practice. At least currently it does - like you said, this is fixable,
> but nobody has signed up to fix it yet.
>
> The main thing that's needed is a zero-input Python distribution - a
> Python runtime, if you will - that (1) gets installed to a "good"
> place (2) does so without asking the user to do anything, (3) can
> coexist with different versions of the runtime, and (4) is easily
> detectable by applications wanting to use it.
The effbot.exe platform (or how it's called) ?
> One other minor component is a small launcher executable, because on
> Windows it's non-trivial to find out which "python.exe" in the task
> manager is running which Python script. Anyway, each app would have a
> small launcher that bootstraps the actual Python script[1]. (Or, if
> there's some way to trick the task manager into displaying something
> besides "python.exe", that'd work too)
exemaker?
Thomas
Dave Brueck
> Dave Brueck <da...@pythonapocrypha.com> writes:
>>Terry Reedy wrote:
>>>If there is something about the default install of Python on Windows
>>>that makes it less desireable or less easy than other platforms,
>>>then maybe that can be fixed. To make installation easier, maybe
>>>someone could write a small .exe that could be frozen with scripts
>>>or run with installers and that would detect the presence/absence of
>>>the needed Python version and offer an auto download and install if
>>>needed.
>>
>>I mostly agree with the sentiment, but it does break down a little in
>>practice. At least currently it does - like you said, this is fixable,
>>but nobody has signed up to fix it yet.
>>
>>The main thing that's needed is a zero-input Python distribution - a
>>Python runtime, if you will - that (1) gets installed to a "good"
>>place (2) does so without asking the user to do anything, (3) can
>>coexist with different versions of the runtime, and (4) is easily
>>detectable by applications wanting to use it.
>
>
> The effbot.exe platform (or how it's called) ?
Yep - something along those lines, plus some docs for app developers. I don't
know if it installs all the stdlib, or just what effbot apps need, but I assume
the former.
>>One other minor component is a small launcher executable, because on
>>Windows it's non-trivial to find out which "python.exe" in the task
>>manager is running which Python script. Anyway, each app would have a
>>small launcher that bootstraps the actual Python script[1]. (Or, if
>>there's some way to trick the task manager into displaying something
>>besides "python.exe", that'd work too)
>
>
> exemaker?
Something similar to that, yes. You'd need an option to generate a console
launcher or a Windows app launcher (maybe his latest version already has this?),
and a way to figure out which version of the runtime to use (rather than specify
the path ahead of time, you'd specify version requirements, and then at runtime
use registry entries to figure out where that runtime is), but the general idea
is the same.
-Dave
Nemesis
>> It will just work. Python installs the DLL if it is missing, and leaves
>> it alone (just incrementing the refcount) if it is present on the target
>> system.
> installs it where? the MS docs seem to indicate that they want you to install
> it in the program directory, rather than in a "shared" location:
As far I remember the Python installer copies this dll in the system32
folder if you install Python as Administrator, instead it leaves the
dll inside the Python folder if you install Python as User.
--
As a computer, I find your faith in technology amusing.
Nemesis
>> What happens if I try to install Python2.4 on a system wich doesn't have
>> the dll?
> It will just work. Python installs the DLL if it is missing, and leaves
> it alone (just incrementing the refcount) if it is present on the target
> system.
OK, so the python installer _does_ ship this dll. So also the win
installer has the redistribution problem, or does they pay for
redistributing msvcr71.dll?
--
Computers follow your orders, not your intentions.
Bengt Richter
>
>--7iMSBzlTiPOCCT2k
>Content-Type: text/plain; charset=us-ascii
>Content-Disposition: inline
+1
But credit where due. Someone has stepped up to a large chunk of the problem:
http://jove.prohosting.com/iwave/ipython/pyMinGW.html
I am running a usable-for-most-purposes version of 2.4, that with the help of
an older version of the above (I should upgrade all those tools, but ;-)
I succeeded in building. It was the only way I could go from 2.3 to 2.4, since
the MS .msi installer stuff from MS does not itself install successfully on my NT4 ;-/
I am thinking that I'd like to make a script that would ease pulling all the pieces
from the net (urllib, and md5 checks to download stuff, a state log that would
permit easy resuming when something glitches, and automated dialogs for typical
installer info re locations preferences etc. But I got to thinking about sourceforge's
downloading interface choosing mirrors, and thought "later" ;-)
Well, when I get my next system ;-) But it may be moot, 'cause it will probably be Linux
or BSD (both of which I have on another old box which is too slow for X ;-)
Trouble is, I have banged on the pinching spots in my old NT shoes long enough
to where they are relatively comfy for my regular ambulations ;-)
Regards,
Bengt Richter
Jeff Epler
> But credit where due. Someone has stepped up to a large chunk of the problem:
>
> http://jove.prohosting.com/iwave/ipython/pyMinGW.html
Yay. I'm glad somebody *is* doing this. Maybe all that is needed is to
"get the word out". Some prepackaged binaries would be nice, however.
Jeff
Jimmy Retzlaff
> I guess I don't understand some people's determination to not have
users
seems no
> different to me than having to install (or upgrade) Shockwave, or
Apple's
> Quicksomething for Windows (not used so much anymore), or RealPlayer,
or
> the lastest upgrade for DirectX, or DivX, or a zip decoder, or any
other
> 3rd party software, to run .xxx files or specialized .exe programs.
(And
> I left out the most direct analogy of a java system.)
The Windows application that I develop and distribute relies on Python
plus 14 other packages (wxPython, pywin32all, ctypes, Numeric, PIL,
etc.). My customers typically install the application on 20-100 user
machines within their organization at one time so it's mandatory that I
make an automated silent installer available. That's a lot easier to do
with py2exe and a Windows installer than it is to do with Python's MSI
and 14 other packages. It's also more robust - the installer is much
simpler and my application is always used with exactly the same Python
environment that was used for QA.
There are also significant hurdles to clear before software can be put
on user machines in an organization like this. The reviews with the IT
groups go much more smoothly since I can state that my installer will
only write files to one folder of the IT group's choosing, put an icon
in the Start Menu, and will only touch the registry to register an
uninstaller. If there were 15 installers being run (even if automated)
we'd have to review each of those individually and my product would
almost never be approved.
I don't actively hide the fact that I use Python, but my customers are
rarely interested in my toolbox - they are too focused on their own
business. Some groups will ask what language I use, and the following
question will always be something like "If we need it to, can it
interact with Java?" or C# or ... that's their only interest in the
language I use. If they open themselves up by asking then I can't help
but badger them with the virtues of Python for a while. :)
> 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.
Many of my users don't have a concept of a "file" unless it's something
they ask their assistant to get from a cabinet. They are typically
corporate executives for very big companies and if they have a computer
problem then a team of IT people get paged to fix it immediately. They
don't "need" to become familiar with anything on a computer - their job
is managing many billions of dollars worth of business every year. They
can use almost every feature of my application if they can move the
mouse and click the left button. That requires training for some of
them, and I feel honored they'll take the time to learn that much in
order to use my software.
> Also, I think it a bit 'anti-social' to hide usage of Python. If all
> Python Windows programs ran with a normal, communally installed
Python,
> then users would gradually get the idea that having Python installed
is
> much like having Shockwave and other utility platforms installed, and
that
> is is part of a 'fully loaded' Windows system to have a .py player
> installed.
I feel the opposite. I've skipped evaluating a number of applications
because they didn't come with their own dedicated JVM. I've spent way
too much of my own time trying to use applications with conflicting JVM
requirements only to give up in the end. It's just a new form of DLL
hell.
As a user, I only want to think about how well an application does what
I need it to do. The more time I spend dealing with supporting
technologies, the less time I spend on the intended task.
> If there is something about the default install of Python on Windows
that
> makes it less desireable or less easy than other platforms, then maybe
> that can be fixed.
Something like Flash is quite special purposed and you don't have tons
of large extension modules that are in common use. You just use the base
system and it is very tightly controlled by one organization to maintain
backwards compatibility. And it is primarily used to augment/replace
HTML pages, so you don't want to download/install the engine each time
you come across another page with Flash content. Applications are
different, you acquire them once and use them over and over and the
runtime environment is much more variable from app to app. You don't
just have to worry about the backward compatibility of Python itself,
but of every extension module in common use and all the combinations
that arise out of that. Again look at the pain of shared JVM use. I
think Microsoft is on the right track to addressing DLL hell now by
recommending that DLLs be installed in the application folder, not the
system folder. That's analogous to using application specific JVMs and
things like py2exe or cx_freeze for Python.
> To make installation easier, maybe someone could write a
> small .exe that could be frozen with scripts or run with installers
and
> that would detect the presence/absence of the needed Python version
and
> offer an auto download and install if needed.
My users only get access to "approved" sites (nothing else shows up in
their DNS). It's hard enough to get my own domain added to the ordained
list, much less a long list like python.org, sourceforge.net,
effbot.org, etc.
All this isn't just for my clients. I have a number of automated
processes that I run on my server that are written in Python. When I
need a new version of some module for one of those processes, I don't
want to spend the time testing it with each of the others to make sure
it didn't break anything. So I build single file executables from my
Python scripts so they are completely self-contained. When I want to
modify a module, then I can test/correct the impact of any new modules
at that point since I'll be in the code anyway. Before I started doing
this, the version of Python and the various extension modules in use on
my server was a couple of years older than the version on my development
machine because I almost never upgraded for fear of breaking several
processes.
Hard drive space is cheap and building exes is easy and I like the
benefits.
Jimmy
p.s. - on the original topic of this thread - I also buy development
tools from Microsoft that ensure I have the right to distribute the
needed DLLs so it's not a concern in my case.
Peter Hansen
> OK, so the python installer _does_ ship this dll. So also the win
> installer has the redistribution problem, or does they pay for
> redistributing msvcr71.dll?
The last I recall reading in this forum was that the regular
distribution is compiled with a copy of the compiler
*provided by* Microsoft.
Whether they really have in a mind a devious strategy
involving getting lots of people to ship software with
the msvcr71.dll file (and the other one: both are needed)
and then sue the pants off them is anyone's guess...
-Peter
Tony Meyer
> OK, so the python installer _does_ ship this dll. So also the
> win installer has the redistribution problem, or does they
> pay for redistributing msvcr71.dll?
If you have a legal copy of one of the commercial MS compilers that includes
msvcr71.dll, you get the right to redistribute it. Many of the python-dev
people have one of these, so one of their copies is being distributed
(exactly whose copy is academic, really). The redistribution is subject to
various conditions, including getting the user to agree to a certain form of
EULA, which the 2.4 and 2.4.1 .msi installers do not do, so they breach the
EULA, yes. All of this is pretty clear in the EULA, and has been said
before, here and on python-dev.
If anyone wanted to help out, and lessen the incredibly remote chance that
MS will take legal action against the 2.4 distribution, then I'm sure that
MvL would be happy to accept patches for the .msi so that an appropriate
"click-through" EULA was part of the installation.
=Tony.Meyer
Tony Meyer
> want you to install it in the program directory, rather than
> in a "shared" location:
>
From
<http://mail.python.org/pipermail/python-list/2005-February/265334.html>:
"""This means to install it into the directory containing python.exe.
Unfortunately, this does not work if your extension is then used in
an embedded Python, e.g. one running as a COM object. In this case,
python.exe will not be the main executable, but, say, outlook.exe will
be. So Microsoft's recommendation to install the DLL into the EXE
directory is flawed for COM and other embedded cases. This is
precisely the reason why the Python installer installs both python24.dll
and msvcr71.dll into system32."""
=Tony.Meyer
Steve Holden
> Terry Reedy wrote:
>
>>I guess I don't understand some people's determination to not have users
>>install fully useable Python on their Windows machines. Doing so seems no
>>different to me than having to install (or upgrade) Shockwave, or Apple's
>>Quicksomething for Windows (not used so much anymore), or RealPlayer,
>>I left out the most direct analogy of a java system.)
>
>
> The Windows application that I develop and distribute relies on Python
> plus 14 other packages (wxPython, pywin32all, ctypes, Numeric, PIL,
> etc.). My customers typically install the application on 20-100 user
> machines within their organization at one time so it's mandatory that I
> make an automated silent installer available. That's a lot easier to do
> with py2exe and a Windows installer than it is to do with Python's MSI
> and 14 other packages. It's also more robust - the installer is much
> simpler and my application is always used with exactly the same Python
> environment that was used for QA.
>
reliable Python with no detectable version inconsistencies and a lean,
mean, sharing, caring 25-program package at fifty megabytes total any
sensible user would jump at the former. Disk is now below a dollar a
gigabyte and you are right, people should get over it. Small may be
beautiful, but for a bunch of related but independent modules,
maintaining the system can lead to inconvenient version lock-step. The
monolithically-installed program is a black box that stands alone.
> There are also significant hurdles to clear before software can be put
> on user machines in an organization like this. The reviews with the IT
> groups go much more smoothly since I can state that my installer will
> only write files to one folder of the IT group's choosing, put an icon
> in the Start Menu, and will only touch the registry to register an
> uninstaller. If there were 15 installers being run (even if automated)
> we'd have to review each of those individually and my product would
> almost never be approved.
>
The refuseniks would probably be justified, too.
> I don't actively hide the fact that I use Python, but my customers are
> rarely interested in my toolbox - they are too focused on their own
> business. Some groups will ask what language I use, and the following
> question will always be something like "If we need it to, can it
> interact with Java?" or C# or ... that's their only interest in the
> language I use. If they open themselves up by asking then I can't help
> but badger them with the virtues of Python for a while. :)
>
>
>>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.
>
>
> Many of my users don't have a concept of a "file" unless it's something
> they ask their assistant to get from a cabinet. They are typically
> corporate executives for very big companies and if they have a computer
> problem then a team of IT people get paged to fix it immediately. They
> don't "need" to become familiar with anything on a computer - their job
> is managing many billions of dollars worth of business every year. They
> can use almost every feature of my application if they can move the
> mouse and click the left button. That requires training for some of
> them, and I feel honored they'll take the time to learn that much in
> order to use my software.
>
Now that's an approach that sounds crafted to ensure pride in one's work
and job satisfaction. It's also correctly mindful of the computer's
peripheral role in most decision-making and recording processes.
>
>>Also, I think it a bit 'anti-social' to hide usage of Python. If all
>>Python Windows programs ran with a normal, communally installed
>> Python,
>>then users would gradually get the idea that having Python installed
>> is
>>much like having Shockwave and other utility platforms installed, and
> that
>>is is part of a 'fully loaded' Windows system to have a .py player
>>installed.
>
>
> I feel the opposite. I've skipped evaluating a number of applications
> because they didn't come with their own dedicated JVM. I've spent way
> too much of my own time trying to use applications with conflicting JVM
> requirements only to give up in the end. It's just a new form of DLL
> hell.
>
I'm with you. This is a pragmatic engineering approach to operating
large numbers of systems with minimum hassle.
Yup. Single point of responsibility is usually also appreciated, given
the finger-pointing that can occur.
> All this isn't just for my clients. I have a number of automated
> processes that I run on my server that are written in Python. When I
> need a new version of some module for one of those processes, I don't
> want to spend the time testing it with each of the others to make sure
> it didn't break anything. So I build single file executables from my
> Python scripts so they are completely self-contained. When I want to
> modify a module, then I can test/correct the impact of any new modules
> at that point since I'll be in the code anyway. Before I started doing
> this, the version of Python and the various extension modules in use on
> my server was a couple of years older than the version on my development
> machine because I almost never upgraded for fear of breaking several
> processes.
>
Way hay! A sound engineering approach pays off. Who would have thought?
> Hard drive space is cheap and building exes is easy and I like the
> benefits.
>
> Jimmy
>
> p.s. - on the original topic of this thread - I also buy development
> tools from Microsoft that ensure I have the right to distribute the
> needed DLLs so it's not a concern in my case.
Jimmy:
Thanks for injecting the voice of experience into this debate. Your use
cases certainly aren't vaporous.
regards
Steve
--
Steve Holden +1 703 861 4237 +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/
Python Web Programming http://pydish.holdenweb.com/
Raymond Hettinger
> People have mentioned the older v6 build scripts/tools still work. Last time I
> tried they seemed a bit out of date.
I routinely use the current CVS to build Py2.4 and Py2.5 with MSC6.
It is effortless and I've had no problems.
Raymond Hettinger
Peter Hansen
> The last I recall reading in this forum was that the regular
> distribution is compiled with a copy of the compiler
> *provided by* Microsoft.
On re-reading, I see this might not be clear enough.
By 'provided by' I meant *donated by*, as in given
free (apparently) to the PSF or at least to one of
the core developers for the purpose of compiling
Python itself. Given the nature of Python, one
might see this as an implicit comment about the
status of the two key DLL files in question and
how concerned Microsoft is (or is not) about their
possible widespread distribution in software whose
authors didn't directly pay MS for the compiler.
A Google search might reveal the message in which
I read that, posted a few months ago I believe.
-Peter
Robin Becker
Last time I tried I think I had to move it one level up to be correct for some
of the python/my extension locations, but perhaps I misremember.
--
Robin Becker
"Martin v. Löwis"
>> The last I recall reading in this forum was that the regular
>> distribution is compiled with a copy of the compiler
>> *provided by* Microsoft.
> By 'provided by' I meant *donated by*, as in given
> free (apparently) to the PSF or at least to one of
> the core developers for the purpose of compiling
> Python itself.
Just for the record: While I do have received such a copy,
this copy isn't actually used to build the binaries. Instead,
I use a copy of the compiler that my employer has licensed
(not that this matters much).
I cannot personally see much difference between using VC6
or VC7.1. One key reason for me to push the change for VC7.1
is that VC7.1 has updated SDK headers, which in turn means
that Python 2.4 supports IPv6 (which wasn't really possible
with VC6). Also, many people who build Python extensions
cannot get a copy of VC6 anymore (because MS stopped selling
it), so if Python was built with VC6, many people could
not build Python extensions.
I cannot see much of a difference because Python would have
to include the CRT in *either* case - whether it is mscvrt4.dll,
or msvc71.dll. Neither of these DLLs is guaranteeed to be
shipped with the operating system; that people got away with
not distributing mscvrt4.dll is only because so much other
software distributes it that it is available on virtually
every system. I predict the same will happen with mscvr71.dll
over time (and then with the CRT that will be shipped with
the next release of VC).
Regards,
Martin
Roger Binns
"Terry Reedy" <tjr...@udel.edu> wrote in message news:mailman.1769.1113320...@python.org...
> I guess I don't understand some people's determination to not have users install fully useable Python on their Windows machines.
Ok, here is how you install BitPim which contains a frozen Python:
- Download and run the setup.exe from www.bitpim.org (The
instructions are the equivalent on Linux and Mac)
This is how you would do it if a "fully usable" Python had to be put on a
machine.
- Download and install Python from www.python.org
- Download and install wxPython from www.wxpython.org making sure to
get the correct platform, Python version, wxPython version and Unicode
setting
- Download and install pyserial from pyserial.sf.net for your platform
- Download and install win32all making sure you get the right Python
version (Windows only)
- Download and install DSV from sf.net/projects/python-dsv
- Download and install APSW from www.rogerbinns.com/apsw.html
(Non-Windows users will also have to compile SQLite 3)
- Download and install the BitPim code
- There are a few other components which non-Windows users typically need
and Windows users don't (eg USB library)
- Now launch the main Python script to start BitPim
The uninstall instructions have the same corresponding lengths. Now for the
second part, you could make some arguments:
- I shouldn't be using other components in order to reduce dependencies
and should instead re-invent the wheel myself.
- I could make some sort of installer that did all the non-Python interpretter
pieces and it would have to be compatible with anyone else doing the same
thing.
The first is a waste of my time and effort, and I do the second except I also
include the Python interpretter meaning there are no dependencies.
> Also, I think it a bit 'anti-social' to hide usage of Python.
http://www.bitpim.org/testhelp/3rdparty.htm
The reality is that users don't care what language your program was written in,
what development methodology you use, how hard it was to write, what editor you
use or how your environment enlightens your mind. They do care that what you
produce works as expected. In fact if it works really well, they may decide
to dig in deeper and try to emulate your language, methodology, procedures,
editors in what they do or may contribute to your project if it is open source.
That is the point at which Python matters.
In all these matters I think it is better to lead by example rather than try
to make people aware of things early in order to perform some sort of attempt
to gain mindshare.
Roger
kosh
> "Terry Reedy" <tjr...@udel.edu> wrote in message
> news:mailman.1769.1113320...@python.org...
>
> > I guess I don't understand some people's determination to not have users
> > install fully useable Python on their Windows machines.
>
> Ok, here is how you install BitPim which contains a frozen Python:
>
> - Download and run the setup.exe from www.bitpim.org (The
> instructions are the equivalent on Linux and Mac)
>
Here is the situation I see. I use debian linux systems. Installing all the
dependencies is trivial and if your program has a debian package it would be
a single command. The reason I don't like these programs that built the
runtime, static link in a bunch of stuff etc is that it is a pain to upgrade
later. If there is a security fix to python 2.4 I know there is ONE copy
installed on the system and that updating it will fix it. If there is a
problem with libpng, libjpeg, kdelibs, zope, apache etc the same is still
true, there is only ONE copy of those items on the system and with a single
command all of them can be updated and fixed.
Under windows I can see why you would want stand alone binaries since it has
no method for dealing with dependencies the way that the bsds and linuxes
can. However for a unix product I always want items to be in their seperate
parts since it makes my life as a programmer and admin a heck of a lot
easier. Actually I tend to avoid any software that is not in the debian main
archives since then it is more of a pain to deal with later.
Keeping track of security updates, feature updates etc for a bunch of
computers with a lot of software from different locations is a royal pain in
the neck. With windows it is worse since you don't even have a centralized
update system.
Roger Binns
> dependencies is trivial and if your program has a debian package it would be
> a single command.
Note that there is *nothing* precluding running using the system Python
other than you have to have the dependencies present. In fact that is how
all the developers run. The binary/frozen packages are provided as a
convenience to the users who just want to use the program and I don't
see any need for them to jump through hoops.
> The reason I don't like these programs that built the
> runtime, static link in a bunch of stuff etc is that it is a pain to upgrade
> later.
True. People on both Gentoo and Debian have told me they are making
proper ebuild/dkpg for BitPim. In both cases nothing came of it
which is why I tell people on those systems to just use the rpm.
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)
The second is dealing with the dependencies. The packager is trying
to do BitPim and finds they have to work with others or need assistance
to deal with the dependencies. Gentoo is months out of date for wxPython
and I have no idea how far behind Debian is. Typically other dependencies
aren't even packaged at all, even though they use distutils (ie all it
takes is figuring out how to do 'python setup.py install' in a way that
keeps the packaging system happy).
> If there is a security fix to python 2.4 I know there is ONE copy
> installed on the system and that updating it will fix it. If there is a
> problem with libpng, libjpeg, kdelibs, zope, apache etc the same is still
> true, there is only ONE copy of those items on the system and with a single
> command all of them can be updated and fixed.
True. Noone forces you to install/run anything. Right now someone on Debian
who wants to use BitPim has one of these choices:
- Fix Debian's packaging so that it contains all of the dependencies and
BitPim itself with the latter being updated every two weeks. This will
keep your scenario above on the right track.
- Bypass Debian's packaging and install the various dependencies manually
and run from "source"
- Use alien and the rpm
> Keeping track of security updates, feature updates etc for a bunch of
> computers with a lot of software from different locations is a royal pain in
> the neck.
True. And the reality is that various Python packages are backwaters/low
priority for the packagers. All it takes is one missing dependency to
throw a spanner in the works.
And as I told the person who originally wanted to package BitPim for Debian,
I will supply all the help and make changes as necessary. Someone from the
distros has to step forward to complete it.
Roger
"Martin v. Löwis"
> - I could make some sort of installer that did all the non-Python interpretter
> pieces and it would have to be compatible with anyone else doing the same
> thing.
>
> The first is a waste of my time and effort, and I do the second except I also
> include the Python interpretter meaning there are no dependencies.
If that works for you and your users, fine - the main point of this
thread is that some users complain they can't do that anymore, because
they have no license to distribute msvcr71. For those users: what is
the reason not to use the approach of shipping an application that
requires a certain version of Python pre-installed on the target
machine?
Regards,
Martin
Peter Lee
>> 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.
Stefan Behnel
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
Roger Binns
"Stefan Behnel" <behn...@gkec.informatik.tu-darmstadt.de> wrote in message news:d3vscb$i8r$1...@lnx107.hrz.tu-darmstadt.de...
>
> 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
Jarek Zgoda
> 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/
long.in....@gmail.com
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
ucn...@gmail.com
RPM distribution of Python.