Is it possible for the installer to check whether or not there is a
pre-existing system-wide launcher, and only do the complicated stuff
if it is actually there?
-jJ
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to pyt
Tim Golden wrote:
> The Python docs have a section on running Python
> on Windows. This is the online version:
>
> http://docs.python.org/using/windows.html
>
> The .chm version should be in c:\python31\doc\python31.chm
Which is more easily accessed via the start menu entry Python creates
for
David H. Burns wrote:
I downloaded what claims to be Python for Windows (3.01). The tutorial
brags a lot about how easy it is to learn, but the tutorials and
instruction seem to be for a Linux or Unix version. There are three
executable programs in the Python directory and no indication which
David H. Burns wrote:
I downloaded what claims to be Python for Windows (3.01). The tutorial
brags a lot about how easy it is to learn, but the tutorials and
instruction seem to be for a Linux or Unix version. There are three
executable programs in the Python directory and no indication which
I downloaded what claims to be Python for Windows (3.01). The tutorial
brags a lot about how easy it is to learn, but the tutorials and
instruction seem to be for a Linux or Unix version. There are three
executable programs in the Python directory and no indication which
should be used to start
> The OEM ready program required that the installed force to program
> files. But as we preinstalled we use your msi with a normal
> parameter: python-2.5.2.msi TARGETDIR=c:\program files\python"
I think the debate was about whether it can be "OEM ready",
even though you still need to pass the TAR
PROTECTED]
Cc: 'Nick Coghlan'; python-dev@python.org
Subject: RE: [Python-Dev] Python for windows.
Hi all,
I didn't look at the thread until this morning.
The OEM ready program required that the installed force to program files.
But as we preinstalled we use your msi with a
#x27;Nick Coghlan'; python-dev@python.org
Subject: Re: [Python-Dev] Python for windows.
> Of course, I don't object to that and still think we should help where we
> can, but if that is true it would make the premise of this thread a little
> misleading, as obviously HP could then make *
> Of course, I don't object to that and still think we should help where we
> can, but if that is true it would make the premise of this thread a little
> misleading, as obviously HP could then make *any* necessary changes without
> our agreement or even knowledge.
Perhaps. However, "help where we
> > [Hrm - looking closer at that HTML link I sent before, it says
> > specifically "Per-machine installs must install to Program Files
> > by default in order to
> > pass this test case" - that seems pretty clear...]
>
> Given that the links in Gerald's examples were under Program Files, I
> had
On 2008-11-28 00:15, Christian Heimes wrote:
> Martin v. Löwis wrote:
>>> All, and not to start flames, but I still do not understand why
>>> applink.c isn't included in python's main (conditionally) instead of
>>> expecting users, many of them novices, to do the build. ???
>>
>> One reason is tha
Mark Hammond wrote:
> Greg writes:
>> Mark Hammond wrote:
>>
>>> The only conflict I see here is the requirement to install into
>> "\Program Files"
>>
>> Doesn't that just mean that if an OEM decides to preinstall it,
>> they need to put it in Program Files? They're at liberty to
>> do that.
>
>
> Applink is roughly explained at
> http://www.openssl.org/support/faq.html#PROG2. The matter was discussed
> about half a year ago but no decision was made. See
> http://mail.python.org/pipermail/python-dev/2008-March/077424.html
>
> applink.c is just a table of integer constants to function poin
Greg writes:
> Mark Hammond wrote:
>
> > The only conflict I see here is the requirement to install into
> "\Program Files"
>
> Doesn't that just mean that if an OEM decides to preinstall it,
> they need to put it in Program Files? They're at liberty to
> do that.
I'm not very familiar with the
Martin v. Löwis wrote:
All, and not to start flames, but I still do not understand why
applink.c isn't included in python's main (conditionally) instead of
expecting users, many of them novices, to do the build. ???
One reason is that I don't know what applink is, and why I should
care about i
Mark Hammond wrote:
The only conflict I see here is the requirement to install into "\Program
Files"
Doesn't that just mean that if an OEM decides to preinstall it,
they need to put it in Program Files? They're at liberty to
do that.
--
Greg
___
Pyt
Bugbee, Larry wrote:
As I recall, OpenSSL, a long while ago stopped, supporting some idiosyncrasies
> associated with Windows I/O and opted for a "cleaner" approach, that of
requiring
developers to link a small file, applink.c, into the app's main.
Could it not be linked into the openssl ext
> > > All, and not to start flames, but I still do not understand why
> > > applink.c isn't included in python's main (conditionally) instead
> > > of expecting users, many of them novices, to do the build. ???
> >
> > One reason is that I don't know what applink is, and why I should care
> >
tin v. Löwis"; Koenig, Gerald; python-dev@python.org
> Subject: Re: [Python-Dev] Python for windows.
>
> Bugbee, Larry <[EMAIL PROTECTED]> wrote:
>
>> For most custom apps this is a simple process of adding "#include
>> applink.c" to the app's
> The only conflict I see here is the requirement to install into "\Program
> Files" and I'm surprised that hasn't been raised in this thread.
The question is whether the "OEM ready" is a property of the installer,
or a property of the installed. The OEM can chose to install Python into
program f
> As I recall, OpenSSL, a long while ago stopped, supporting some
> idiosyncrasies associated with Windows I/O and opted for a "cleaner"
> approach, that of requiring developers to link a small file,
> applink.c, into the app's main. applink.c is provided by the OpenSSL
> folks.
[...]
Ok, this e
Mark Hammond wrote:
BTW - isn't there also a "\Program Files" requirement...?
The requirement as I read it is that /Program Files be the over-rideable
*default*, as is normal for Windows programs. HP installed 2.2 on my
machine in /Python2.2. Since HP does the installation, I presume they
nssen [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 26, 2008 5:54 PM
To: Bugbee, Larry
Cc: "Martin v. Löwis"; Koenig, Gerald; python-dev@python.org
Subject: Re: [Python-Dev] Python for windows.
Bugbee, Larry <[EMAIL PROTECTED]> wrote:
> For most custom apps this is a
> Right, and I agree with it. However, that is HP's choice, and while
> there is a theoretical possibility that users break their systems, in
> practice, most users are too scared to actually attempt such breakage.
>
> However, "OEM ready" sounds like a good goal to achieve.
Agreed too - I don't
Bugbee, Larry <[EMAIL PROTECTED]> wrote:
> For most custom apps this is a simple process of adding "#include applink.c"
> to the app's main(). The problem for Python developers is that their Python
> program is not main(), and if python.exe does not have the OPENSSL_Applink
> interface, they c
Martin v. Löwis <[EMAIL PROTECTED]> wrote:
> Perhaps. I wouldn't go so far, though. It's surely puzzling if a system
> comes with a pre-installed Python, but if that Python actually works,
> I don't think that does much damage.
OS X does come with pre-installed Python, so this is a debate we have
> > All, and not to start flames, but I still do not understand why
> > applink.c isn't included in python's main (conditionally) instead
> > of expecting users, many of them novices, to do the build. ???
>
> One reason is that I don't know what applink is, and why I should
> care about it. (I
> All, and not to start flames, but I still do not understand why
> applink.c isn't included in python's main (conditionally) instead of
> expecting users, many of them novices, to do the build. ???
One reason is that I don't know what applink is, and why I should
care about it. (I may have known
> IIUC, the test suite is about having the Python installer certified as "OEM
> Ready", which means a few special things - including, IIUC, the "right" to
> be installed in a new PC. My broader point is that I would advise against
> any application vendor reusing the standard Python installer for
> I can promise you Python on our system Python work perfectly.
I'm sure it does :) I'm more concerned about *your* apps not working when
the user, or a "helpful" friend, uninstalls this Python thing that they
don't use. I'm very interested to know why you don't see this as a
significant problem
clean.
GErald
-Original Message-
From: "Martin v. Löwis" [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 26, 2008 2:32 PM
To: [EMAIL PROTECTED]
Cc: Koenig, Gerald; python-dev@python.org
Subject: Re: [Python-Dev] Python for windows.
> But these are written with application
> > But these are written with applications in mind - Python isn't an
> > application - its used to *write* applications. I don't see a good
> reason
> > to support these guidelines. I do see a reason to help support
> people
> > ensure their Python implemented applications can meet the guideline
ditionally) instead of
expecting users, many of them novices, to do the build. ???
Larry
[snip]
Message: 2
Date: Wed, 26 Nov 2008 19:06:44 +
From: "Koenig, Gerald" <[EMAIL PROTECTED]>
Subject: [Python-Dev] Python for windows.
To: "python-dev@python.org"
Message
> But these are written with applications in mind - Python isn't an
> application - its used to *write* applications. I don't see a good reason
> to support these guidelines. I do see a reason to help support people
> ensure their Python implemented applications can meet the guidelines, but
> I'd
Martin writes:
> > c:\program
> files\python\lib\distutils\command\\wininst-8.0.exe
>
> Hmm. These binaries are not meant to be run as executables themselves.
> Instead, they are meant to be integrated into setup programs as-is.
> wininst-6.0.exe, in particular, is created by MSVC
> - Some of the executable deliver in the python package It does not
> have manifest that is compliant with UAC guidelines..
> c:\program files\python\lib\distutils\command\\wininst-6.0.exe
> c:\program files\python\lib\distutils\command\\wininst-7.1.exe
>
Sent: Wednesday, November 26, 2008 2:03 PM
To: [EMAIL PROTECTED]; python-dev@python.org
Subject: Re: [Python-Dev] Python for windows.
Hi Mark,
Well we are having a lot of our teams using python are the script languages :)
It is not only one team using it
That why we use the normal installer :)
G
26, 2008 1:59 PM
To: Koenig, Gerald; python-dev@python.org
Subject: RE: [Python-Dev] Python for windows.
> I completely understand that this is a volunteer organization.
> That why I am already proposing that HP will submit for your guys after
> we figure out how to fix the issues if it is
> I completely understand that this is a volunteer organization.
> That why I am already proposing that HP will submit for your guys after
> we figure out how to fix the issues if it is possible to fix them of
> course.
I don't fully understand why it is in HPs interests to install a normal
python
, 2008 12:35 PM
To: python-dev@python.org
Subject: RE: [Python-Dev] Python for windows.
Hi all,
Right now we are including 2.5.2
I am planning on rolling to 2.6 very soon.
I completely understand that this is a volunteer organization.
That why I am already proposing that HP will submit for your guys
any version
numbers inside.
Gerald
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Terry Reedy
Sent: Wednesday, November 26, 2008 12:18 PM
To: python-dev@python.org
Subject: Re: [Python-Dev] Python for windows.
Koenig, Gerald wrote:
> I
> Now I am having a small issue and I was wondering how I can solve it.
>
> So I would like to know who should I contact to be able to work on that issue
> together ?
Please understand how open source development works: lots of volunteers,
few formal commitments.
If you feel it's a "political i
Koenig, Gerald wrote:
I am working For Hewlett-Packard designing PC Consumer Desktop
We have been including Python since over 10 years now on our systems.
I am writing this on a Pavilion that came with Python2.2. I hope you
are able to continue including Python.
Now I am having a small is
On Wed, Nov 26, 2008 at 11:24, Koenig, Gerald <[EMAIL PROTECTED]> wrote:
> Hi,
>
> This is a question about development how can python meet "OEM Ready programs".
> Right now most of python is passing that programs but not all of it.
>
> Right now some of the executable are failing some of the tests
t want to swamp that mailing list with a lot of
things.
Gerald
-Original Message-
From: Leif Walsh [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 26, 2008 11:21 AM
To: Koenig, Gerald
Cc: python-dev@python.org
Subject: Re: [Python-Dev] Python for windows.
This list is for the develo
This list is for the development of python. Questions about
programming with python go to c.l.python or python-list at python dot
org.
If your question is about the development of python, you can probably
just ask here.
On Wed, Nov 26, 2008 at 2:06 PM, Koenig, Gerald <[EMAIL PROTECTED]> wrote:
>
Hi all,
I am working For Hewlett-Packard designing PC Consumer Desktop
We have been including Python since over 10 years now on our systems.
It is a wonderful language and very powerful.
Now I am having a small issue and I was wondering how I can solve it.
So I would like to know who should I
Luke Dunstan wrote:
> OK. Actually I think distutils will be the last thing to be ported because
> it is not necessary for using the rest of Python. Does distutils has support
> for cross-compiling anyway?
No, it doesn't.
> OK, but what about ANSI C headers like signal.h? I expected HAVE_SIGNAL
- Original Message -
From: ""Martin v. Löwis"" <[EMAIL PROTECTED]>
To: "Luke Dunstan" <[EMAIL PROTECTED]>
Cc:
Sent: Thursday, May 04, 2006 5:03 AM
Subject: Re: [Python-Dev] Python for Windows CE
> Luke Dunstan wrote:
>> 1. Is there
Luke Dunstan wrote:
> 1. Is there any reason in principle why patches for Windows CE support would
> be rejected?
No, not in principle. Of course,
- the patch shouldn't break anything
- you should state an explicit commitment to support the port for
some years (or else it might get removed at t
Hi,
I would like to explore the possibility of submitting patches to allow
Python to work on Windows CE out of the box. I have a few questions in
preparation:
1. Is there any reason in principle why patches for Windows CE support would
be rejected?
2. Should I submit unified diffs or context
51 matches
Mail list logo
