[Python-Dev] distutils doesn't use some compiler options when building
Hi,
I encountered a weird problem using distutils.
Generally, distutils try to use the same compiler options used for
building Python interpreter,
but it looks like some of them are omitted sometimes.
- CPPFLAGS are not retrieved from the config and only ones in env are used.
- OPT is retrieved from the config, but it's only used when env has CFLAGS.
See: http://svn.python.org/view/python/trunk/Lib/distutils/sysconfig.py
"""
def customize_compiler(compiler):
...
if compiler.compiler_type == "unix":
(cc, cxx, opt, cflags, ccshared, ldshared, so_ext) = \
get_config_vars('CC', 'CXX', 'OPT', 'CFLAGS',
'CCSHARED', 'LDSHARED', 'SO')
if 'CC' in os.environ:
cc = os.environ['CC']
if 'CXX' in os.environ:
cxx = os.environ['CXX']
if 'LDSHARED' in os.environ:
ldshared = os.environ['LDSHARED']
if 'CPP' in os.environ:
cpp = os.environ['CPP']
else:
cpp = cc + " -E" # not always
if 'LDFLAGS' in os.environ:
ldshared = ldshared + ' ' + os.environ['LDFLAGS']
if 'CFLAGS' in os.environ:
cflags = opt + ' ' + os.environ['CFLAGS']
ldshared = ldshared + ' ' + os.environ['CFLAGS']
if 'CPPFLAGS' in os.environ:
cpp = cpp + ' ' + os.environ['CPPFLAGS']
cflags = cflags + ' ' + os.environ['CPPFLAGS']
ldshared = ldshared + ' ' + os.environ['CPPFLAGS']
cc_cmd = cc + ' ' + cflags
compiler.set_executables(
preprocessor=cpp,
compiler=cc_cmd,
compiler_so=cc_cmd + ' ' + ccshared,
compiler_cxx=cxx,
linker_so=ldshared,
linker_exe=cc)
compiler.shared_lib_extension = so_ext
"""
Are these logics are intentional or just a bug?
If this is intentional behavior, why is that being this way?
Thanks,
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Python for windows.
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 contact to be able to work on that issue together ? The issue is about some requirement I need to have on our systems and even tools need to pass those requirement. Regards Gerald Koenig Software Builds Architect Hewlett-Packard Work Phone: +(1) 408 873 6202 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python for windows.
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 contact to be able to work on that issue > together ? > > The issue is about some requirement I need to have on our systems and even > tools need to pass those requirement. > > Regards > > Gerald Koenig > Software Builds Architect > Hewlett-Packard > Work Phone: +(1) 408 873 6202 > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/leif.walsh%40gmail.com > -- Cheers, Leif ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python for windows.
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. Only few test are failings. That why I need a contact I don'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: [email protected] Subject: Re: [Python-Dev] Python for windows. 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 contact to be able to work on that issue > together ? > > The issue is about some requirement I need to have on our systems and even > tools need to pass those requirement. > > Regards > > Gerald Koenig > Software Builds Architect > Hewlett-Packard > Work Phone: +(1) 408 873 6202 > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/leif.walsh%40gmail.com > -- Cheers, Leif ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python for windows.
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. Only few test > are failings. > > That why I need a contact I don't want to swamp that mailing list with a lot > of things. > If the failings are because of a bug in Python, then bugs.python.org or here is the right place. Otherwise comp.lang.python/python-list is the proper place. Don't worry about swamping the list with questions; it's there to answer questions and already gets lots of traffic. -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] 2.6.1 and 3.0
> I always wondered why it was necessary to write msi.py in the first > place. Maintaining it is surely a big effort and requires understanding > of a dark library which a few people have (IMO it's a much higher effort > than setting up automated tests in a bunch of VM, which you said is "not > worth it"). > > There are plenty of MSI installer generator programs Originally it was written because none of the MSI generator programs were capable of packaging Python. In particular, none was capable of creating 64-bit packages (which were first needed to create the Itanium packages). > and Python's needs > do not seem so weird to require a custom MSI generator. Python's needs are fairly weird, so I'm very skeptical that any other generator is capable of doing what msi.py does (or, if it was capable of doing that, that it was then any simpler than msi.py). The critical part is that you need a powerful way to specify what files to package (having to select them in a UI is unacceptable, as the set of files constantly changes - the current generator can cope with many types of file additions without needing any change). > I'm sure the > Python Software Foundation would easily get a free license of one of the > good commercial MSI installer generators. Can you recommend a specific one? In addition, I'm also skeptical wrt. commercial setup tools. We had been using Wise for a while, and it was a management problem because the license was only available on a single machine - so it was difficult for anybody else to jump in and do a release. > In short: if msi.py and the fact it breaks is part of the issue here, > it's very easy to solve in my opinion. I'm very skeptical that this statement is actually true. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python for windows.
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 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 ? The issue is about some requirement I need to have on our systems and even tools need to pass those requirement. If you are looking for one person to give you professional support (which would not be me for your problem) with professional discretion for professional pay, you should say so. As far as I know, the Python Software Foundation does not have an on-call corporate-support person. If you are will to take your chances with volunteer support from whoever responds to each item, then you can choose between the general list for issues relating to past and current releases or the bug tracker or this list for issue relating to future releases (including Pythonx.y.z bug-fix releases). Without more information (Which version is not passing "OEM Ready"? Have previous versions passed such?), it is hard to say more. Terry Jan Reedy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] 2.6.1 and 3.0
Martin v. Löwis wrote: I always wondered why it was necessary to write msi.py in the first place. Maintaining it is surely a big effort and requires understanding of a dark library which a few people have (IMO it's a much higher effort than setting up automated tests in a bunch of VM, which you said is "not worth it"). There are plenty of MSI installer generator programs Originally it was written because none of the MSI generator programs were capable of packaging Python. In particular, none was capable of creating 64-bit packages (which were first needed to create the Itanium packages). and Python's needs do not seem so weird to require a custom MSI generator. Python's needs are fairly weird, so I'm very skeptical that any other generator is capable of doing what msi.py does (or, if it was capable of doing that, that it was then any simpler than msi.py). The critical part is that you need a powerful way to specify what files to package (having to select them in a UI is unacceptable, as the set of files constantly changes - the current generator can cope with many types of file additions without needing any change). Wix is an msi creator (open source) that takes XML files as the input. It is also capable of creating 64bit installers. At Resolver Systems we use CPython scripts to generate the XML as input for Wix. It would still need *some* code therefore, but maybe simpler if someone wanted to do the work. :-) It would work well with the files being generated from an XML templating language like Mako which is what we will be switching to at Resolver Systems. http://wix.sourceforge.net/ Michael Foord I'm sure the Python Software Foundation would easily get a free license of one of the good commercial MSI installer generators. Can you recommend a specific one? In addition, I'm also skeptical wrt. commercial setup tools. We had been using Wise for a while, and it was a management problem because the license was only available on a single machine - so it was difficult for anybody else to jump in and do a release. In short: if msi.py and the fact it breaks is part of the issue here, it's very easy to solve in my opinion. I'm very skeptical that this statement is actually true. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] 2.6.1 and 3.0
Martin, What is the rationale behind using an MSI ? Has anyone attempted to create a Python installer using something a bit simpler, like NSIS [ http://nsis.sourceforge.net/Main_Page]? If not, what are the reasons? Joe On Wed, Nov 26, 2008 at 3:03 PM, "Martin v. Löwis" <[EMAIL PROTECTED]>wrote: > > I always wondered why it was necessary to write msi.py in the first > > place. Maintaining it is surely a big effort and requires understanding > > of a dark library which a few people have (IMO it's a much higher effort > > than setting up automated tests in a bunch of VM, which you said is "not > > worth it"). > > > > There are plenty of MSI installer generator programs > > Originally it was written because none of the MSI generator programs > were capable of packaging Python. In particular, none was capable of > creating 64-bit packages (which were first needed to create the > Itanium packages). > > > and Python's needs > > do not seem so weird to require a custom MSI generator. > > Python's needs are fairly weird, so I'm very skeptical that any other > generator is capable of doing what msi.py does (or, if it was capable > of doing that, that it was then any simpler than msi.py). > > The critical part is that you need a powerful way to specify what files > to package (having to select them in a UI is unacceptable, as the set > of files constantly changes - the current generator can cope with many > types of file additions without needing any change). > > > I'm sure the > > Python Software Foundation would easily get a free license of one of the > > good commercial MSI installer generators. > > Can you recommend a specific one? > > In addition, I'm also skeptical wrt. commercial setup tools. We had been > using Wise for a while, and it was a management problem because the > license was only available on a single machine - so it was difficult > for anybody else to jump in and do a release. > > > In short: if msi.py and the fact it breaks is part of the issue here, > > it's very easy to solve in my opinion. > > I'm very skeptical that this statement is actually true. > > Regards, > Martin > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/josepharmbruster%40gmail.com > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python for windows.
> 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 issue", and best resolved by signing contracts and whatnot, contact the PSF. If it's a technical issue that you consider a bug, or missing feature, you can discuss it here - unless you can already formulate a specific bug report, which should go to bugs.python.org. If it's technical, but requires signing an NDA to learn what the issue is, it will be very difficult. Everything we do in Python is public, archived, indexed, and visible in any way you can imagine. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] 2.6.1 and 3.0
> Wix is an msi creator (open source) that takes XML files as the input. > It is also capable of creating 64bit installers. At Resolver Systems we > use CPython scripts to generate the XML as input for Wix. > > It would still need *some* code therefore, but maybe simpler if someone > wanted to do the work. :-) I had looked at WiX before, and found that it can't do out of the box what I want to do - I still would need to generate the input files, e.g. with a script (and I'm happy to hear that you can confirm that analysis). I also had quite some problems understanding it, and can understand msi.py much better (surprise, surprise). For a newcomer, my feeling is that learning WiX and learning msi.py is about the same effort - you really need to "get" MSI files. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] 2.6.1 and 3.0
Martin v. Löwis wrote: >> I'm sure the >> Python Software Foundation would easily get a free license of one of the >> good commercial MSI installer generators. > > Can you recommend a specific one? > > In addition, I'm also skeptical wrt. commercial setup tools. We had been > using Wise for a while, and it was a management problem because the > license was only available on a single machine - so it was difficult > for anybody else to jump in and do a release. > I've also had terrible times with installshield and other things in the past, but I've been very very pleased with WiX: http://wix.sourceforge.net/ Free, open source, and it gave me absolute control over how the MSI and MSM modules were built, using text files so I could store them in version control, spit out installers from our automated build, etc. The source format is XML (shrug), so on that project we even wrote a WiX parser to calculate SCons dependencies all the way through the MSM to the MSI, so that we could tell when a source file was changed what installers needed to be resigned and shipped to customers. It's really nice to be able to code review installer changes, and to have automated builds spit out .msi files alongside the .debs and .rpms and more. -- Elliot Murphy | https://launchpad.net/~statik/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] 2.6.1 and 3.0
> What is the rationale behind using an MSI ? Has anyone attempted to > create a Python installer using something a bit simpler, like NSIS > [http://nsis.sourceforge.net/Main_Page]? If not, what are the reasons? It's a lot of effort to look at any such tool (and I really mean a *lot* of effort - like a full week). That's why nobody did it. When I looked at MSI, I did it because it has a few unique features: - it supports 64-bit installers, which now is an absolute requirement (people really do want to use the AMD64 binaries) a shallow look at the feature list of NSIS suggest that NSIS would fail this requirement. - it supports installation through Windows Domain policy. I would be willing to drop this requirement, but I believe some users would not be happy. Nothing but MSI has this capability (by design of Windows Active Directory). Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 after we
figure out how to fix the issues if it is possible to fix them of course.
The OEM Ready program is:
http://msdn.microsoft.com/en-us/windowsvista/cc315067.aspx
Personally I am ready to do the job of submitting and testing if you pass all
the tests.
You can find some info about all those test here also:
http://www.codeproject.com/KB/vista/Certified_for_Vista.aspx?display=PrintAll&fid=406261&df=90&mpp=25&noise=3&sort=Position&view=Quick&fr=26
The list of issues are pretty simple:
- 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
c:\program files\python\lib\distutils\command\\wininst-8.0.exe
We could add a manifest manually outside the executable if
there is no manifest at all in those.
- This
c:\windows\installer\{110eb5c4-e995-4cfb-ab80-a5f315bea9e8}\python_icon.exe do
not answers to the Restart Manager Aware
Not sure what can be the solution for that one.
- Last one is some of your executable do not contain 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: [email protected]
Subject: Re: [Python-Dev] Python for windows.
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 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 ?
> The issue is about some requirement I need to have on our systems and even
> tools need to pass those requirement.
If you are looking for one person to give you professional support
(which would not be me for your problem) with professional discretion
for professional pay, you should say so. As far as I know, the Python
Software Foundation does not have an on-call corporate-support person.
If you are will to take your chances with volunteer support from whoever
responds to each item, then you can choose between the general list for
issues relating to past and current releases or the bug tracker or this
list for issue relating to future releases (including Pythonx.y.z
bug-fix releases). Without more information (Which version is not
passing "OEM Ready"? Have previous versions passed such?), it is hard to
say more.
Terry Jan Reedy
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/gerald.koenig%40hp.com
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python for windows.
Hi Terry, And like you I really want to keep python on our systems. That why I am contacting python Foundation and try to fix those issues together. We are already running all those tests in house here. Gerald -Original Message- From: Koenig, Gerald Sent: Wednesday, November 26, 2008 12:35 PM To: [email protected] 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 after we figure out how to fix the issues if it is possible to fix them of course. The OEM Ready program is: http://msdn.microsoft.com/en-us/windowsvista/cc315067.aspx Personally I am ready to do the job of submitting and testing if you pass all the tests. You can find some info about all those test here also: http://www.codeproject.com/KB/vista/Certified_for_Vista.aspx?display=PrintAll&fid=406261&df=90&mpp=25&noise=3&sort=Position&view=Quick&fr=26 The list of issues are pretty simple: - 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 c:\program files\python\lib\distutils\command\\wininst-8.0.exe We could add a manifest manually outside the executable if there is no manifest at all in those. - This c:\windows\installer\{110eb5c4-e995-4cfb-ab80-a5f315bea9e8}\python_icon.exe do not answers to the Restart Manager Aware Not sure what can be the solution for that one. - Last one is some of your executable do not contain 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: [email protected] Subject: Re: [Python-Dev] Python for windows. 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 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 ? > The issue is about some requirement I need to have on our systems and even > tools need to pass those requirement. If you are looking for one person to give you professional support (which would not be me for your problem) with professional discretion for professional pay, you should say so. As far as I know, the Python Software Foundation does not have an on-call corporate-support person. If you are will to take your chances with volunteer support from whoever responds to each item, then you can choose between the general list for issues relating to past and current releases or the bug tracker or this list for issue relating to future releases (including Pythonx.y.z bug-fix releases). Without more information (Which version is not passing "OEM Ready"? Have previous versions passed such?), it is hard to say more. Terry Jan Reedy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/gerald.koenig%40hp.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] 2.6.1 and 3.0
> I've had good results with Advanced Installer: > http://www.advancedinstaller.com/feats-list.html So how much effort would it be to create a Python installer? Could you kindly provide one? Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] 2.6.1 and 3.0
On mer, 2008-11-26 at 21:03 +0100, "Martin v. Löwis" wrote: > > I'm sure the > > Python Software Foundation would easily get a free license of one of the > > good commercial MSI installer generators. > > Can you recommend a specific one? I've had good results with Advanced Installer: http://www.advancedinstaller.com/feats-list.html It does support 64-bit packages, and it uses a XML file as input. It supports Vista and UAC, per-user and per-machine install, registry modification, environment variables, upgrades/downgrades/side installs, online installs. And it's free as in beer. The commercial version has many more features, but I don't think Python needs them. But the basic idea is that this tool totally abstracts the MSI details. I know *nothing* of MSI but I'm fully able to use this tool and produce installers with more features than those I notice within Python's installer. -- Giovanni Bajo Develer S.r.l. http://www.develer.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 possible to fix them of
> course.
I don't fully understand why it is in HPs interests to install a normal
python.dev installer, and have their other bundled software rely on it
working forever. IMO it is likely people will not understand the
association, and may upgrade or remove the package.
Wouldn't it make more sense for HP to treat Python as a "private" tool and
bundle it hidden away inside their applications? This is the exact approach
many applications written in Python take - I can't think of any commercial
applications that rely on the standard installer - think the Python
implemented IDEs, the various Zope windows binaries, etc.
Or obviously I'm missing some key point :)
> The OEM Ready program is: http://msdn.microsoft.com/en-
> us/windowsvista/cc315067.aspx
> Personally I am ready to do the job of submitting and testing if you
> pass all the tests.
>
> You can find some info about all those test here also:
>
> http://www.codeproject.com/KB/vista/Certified_for_Vista.aspx?display=Pr
> intAll&fid=406261&df=90&mpp=25&noise=3&sort=Position&view=Quick&fr=26
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 never advise such people to install the python.org installer and have
their application use Python from that directory.
In other words: Python implemented apps should meet the guidelines, but as
such apps shouldn't use the standard installer, there is no need for Python
itself to meet them.
> - 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
> c:\program files\python\lib\distutils\command\\wininst-
> 8.0.exe
These are stubs for installers. It is the installers created from these
stubs that need the manifest, as the manifest requirements will differ for
each use of the stub.
Ditto for python.exe etc - its impossible to add a reasonable manifest, as
the manifest requirements would depend entirely on what the python program
itself does. There is no way python.exe can know what it will be asked to
do.
>
> We could add a manifest manually outside the executable
> if there is no manifest at all in those.
See above - we don't know ahead of time what an appropriate manifest is. I
agree manifests need thought and work for Python, but I'm fairly sure the
answer isn't to try and come up with them ahead of time and assume they
apply universally.
> - This c:\windows\installer\{110eb5c4-e995-4cfb-ab80-
> a5f315bea9e8}\python_icon.exe do not answers to the Restart Manager
> Aware
That sounds like something nice to have, but assuming we recommend against
using the standard Python installer for 3rd party applications, this is a
problem for the application installer, not ours. In other words, I'm sure
we'd welcome a fix to this, but I'd still recommend against using our
installer anyway!
> - Last one is some of your executable do not contain any
> version numbers inside.
If the binaries don't currently include the python version number, I'd agree
that would be a nice addition.
Maybe your and others lives would be made easier if the Python MSI installer
was split up to support "merge modules"? That way you could roll your own
installer that met any guidelines or requirements that mattered to you,
while still ensuring you got all the files that the official installer would
have installed. I'm hand-waving a little here, but it sounds like we can do
more to help *others* meet guidelines for their Python based apps instead of
trying and meet it for our installer...
Cheers,
Mark
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 :) Gerald -Original Message- From: Mark Hammond [mailto:[EMAIL PROTECTED] On Behalf Of Mark Hammond Sent: Wednesday, November 26, 2008 1:59 PM To: Koenig, Gerald; [email protected] 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 possible to fix them of > course. I don't fully understand why it is in HPs interests to install a normal python.dev installer, and have their other bundled software rely on it working forever. IMO it is likely people will not understand the association, and may upgrade or remove the package. Wouldn't it make more sense for HP to treat Python as a "private" tool and bundle it hidden away inside their applications? This is the exact approach many applications written in Python take - I can't think of any commercial applications that rely on the standard installer - think the Python implemented IDEs, the various Zope windows binaries, etc. Or obviously I'm missing some key point :) > The OEM Ready program is: http://msdn.microsoft.com/en- > us/windowsvista/cc315067.aspx > Personally I am ready to do the job of submitting and testing if you > pass all the tests. > > You can find some info about all those test here also: > > http://www.codeproject.com/KB/vista/Certified_for_Vista.aspx?display=Pr > intAll&fid=406261&df=90&mpp=25&noise=3&sort=Position&view=Quick&fr=26 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 never advise such people to install the python.org installer and have their application use Python from that directory. In other words: Python implemented apps should meet the guidelines, but as such apps shouldn't use the standard installer, there is no need for Python itself to meet them. > - 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 > c:\program files\python\lib\distutils\command\\wininst- > 8.0.exe These are stubs for installers. It is the installers created from these stubs that need the manifest, as the manifest requirements will differ for each use of the stub. Ditto for python.exe etc - its impossible to add a reasonable manifest, as the manifest requirements would depend entirely on what the python program itself does. There is no way python.exe can know what it will be asked to do. > > We could add a manifest manually outside the executable > if there is no manifest at all in those. See above - we don't know ahead of time what an appropriate manifest is. I agree manifests need thought and work for Python, but I'm fairly sure the answer isn't to try and come up with them ahead of time and assume they apply universally. > - This c:\windows\installer\{110eb5c4-e995-4cfb-ab80- > a5f315bea9e8}\python_icon.exe do not answers to the Restart Manager > Aware That sounds like something nice to have, but assuming we recommend against using the standard Python installer for 3rd party applications, this is a problem for the application installer, not ours. In other words, I'm sure we'd welcome a fix to this, but I'd still recommend against using our installer anyway! > - Last one is some of your executable do not contain any > version numbers inside. If the binaries don't currently include the python version number, I'd agree that would be a nice addition. Maybe your and others lives would be made easier if the Python MSI installer was split up to support "merge modules"? That way you could roll your own installer that met any guidelines or requirements that mattered to you, while still ensuring you got all the files that the official installer would have installed. I'm hand-waving a little here, but it sounds like we can do more to help *others* meet guidelines for their Python based apps instead of trying and meet it for our installer... Cheers, Mark ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python for windows.
Hi Mark, See below my answers, We install your installer, for people to use python are the main language script on the system. My team recommend others team to use this as the main scripting languages for different software's, Due to that we use the standard install and people developed their script on the systems. We also leave it on the system for our customer later if they want to use special function of our consumer desktop like application drivers recovery for example. As it is on the system it would need to be passing those requirement for OEM ready because we use python like an application in our case to developed script / programs using your normal installer. This is the main reason we have it on all our system since over 10 years now :) Gerald -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Koenig, Gerald Sent: Wednesday, November 26, 2008 2:03 PM To: [EMAIL PROTECTED]; [email protected] 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 :) Gerald -Original Message- From: Mark Hammond [mailto:[EMAIL PROTECTED] On Behalf Of Mark Hammond Sent: Wednesday, November 26, 2008 1:59 PM To: Koenig, Gerald; [email protected] 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 possible to fix them of > course. I don't fully understand why it is in HPs interests to install a normal python.dev installer, and have their other bundled software rely on it working forever. IMO it is likely people will not understand the association, and may upgrade or remove the package. Wouldn't it make more sense for HP to treat Python as a "private" tool and bundle it hidden away inside their applications? This is the exact approach many applications written in Python take - I can't think of any commercial applications that rely on the standard installer - think the Python implemented IDEs, the various Zope windows binaries, etc. Or obviously I'm missing some key point :) > The OEM Ready program is: http://msdn.microsoft.com/en- > us/windowsvista/cc315067.aspx > Personally I am ready to do the job of submitting and testing if you > pass all the tests. > > You can find some info about all those test here also: > > http://www.codeproject.com/KB/vista/Certified_for_Vista.aspx?display=Pr > intAll&fid=406261&df=90&mpp=25&noise=3&sort=Position&view=Quick&fr=26 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 never advise such people to install the python.org installer and have their application use Python from that directory. In other words: Python implemented apps should meet the guidelines, but as such apps shouldn't use the standard installer, there is no need for Python itself to meet them. > - 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 > c:\program files\python\lib\distutils\command\\wininst- > 8.0.exe These are stubs for installers. It is the installers created from these stubs that need the manifest, as the manifest requirements will differ for each use of the stub. Ditto for python.exe etc - its impossible to add a reasonable manifest, as the manifest requirements would depend entirely on what the python program itself does. There is no way python.exe can know what it will be asked to do. > > We could add a manifest manually outside the executable > if there is no manifest at all in those. See above - we don't know ahead of time what an appropriate manifest is. I agree manifests need thought and work for Python, but I'm fairly sure the answer isn't to try and come up with them ahead of time and assume they apply universally. > - This c:\windows\installer\{110eb5c4-e995-4cfb-ab80- > a5f315bea9e8}\python_icon.exe do not answers to the Restart Manager > Aware That sounds like something nice to have, but assuming we recommend against using the standard Python installer for 3rd party applications, this is a problem for the application installer, not ours. In other words, I'm sure we'd welcome a fix to this, but I'd still recommend against using our installer anyway! > - Last one is some of your executable do not contain any > version numbers inside. If the binaries don't
Re: [Python-Dev] [Python-3000] 2.6.1 and 3.0
Giovanni Bajo wrote: On mer, 2008-11-26 at 21:03 +0100, "Martin v. Löwis" wrote: I'm sure the Python Software Foundation would easily get a free license of one of the good commercial MSI installer generators. Can you recommend a specific one? I've had good results with Advanced Installer: http://www.advancedinstaller.com/feats-list.html It does support 64-bit packages, and it uses a XML file as input. It supports Vista and UAC, per-user and per-machine install, registry modification, environment variables, upgrades/downgrades/side installs, online installs. And it's free as in beer. The commercial version has many more features, but I don't think Python needs them. The free edition is missing at least one important feature: Merge Modules into your installation Create self-contained MSI packages, by including and configuring the required merge modules. Christian ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python for windows.
> - 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
> 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 6.0, which isn't
even capable of dealing with manifests.
Would it help compliance if we renamed them into .dat, so that the
conformance test doesn't recognize them as .exe files? If that doesn't
trick it, we could also binary-invert the contents (or the first 4 bytes).
> - This
> c:\windows\installer\{110eb5c4-e995-4cfb-ab80-a5f315bea9e8}\python_icon.exe
> do not answers to the Restart Manager Aware
> Not sure what can be the solution for that one.
Can you please elaborate? How does one detect that something is Restart
Manager Aware? The file, again, is not ever meant to be run. Instead,
it only serves as a container for icons. If it helps to use a different
icon container (e.g. a DLL), that might solve the problem.
Alternatively, if you can suggest the most trivial "hello world" style
application that is Restart Manager Aware, that would also probably
solve the problem.
See PC/empty.c for the source of python_icons.exe.
> - Last one is some of your executable do not contain any version
> numbers inside.
I was tempted to say "this is not true", but it probably is - only
pythonxy.dll has the version resource.
Patches are welcome. IIUC, PC/python_nt.rc is where the version resource
for pythonxy.dll is defined, and PC/python_exe.rc defines the, well,
.exe resources. For compliance, it's probably ok if python_exe.rc
includes python_nt.rc, but it would probably be better if the version
of python.exe didn't say "Python DLL" for "InternalName". So if you can
come up with a series of defines and #includes that solves it all
without any code duplication - that would be appreciated.
For the other executables (other than python.exe and pythonw.exe):
they aren't really executables. So if renaming them to .dll or
even to something else solves the problem, we can happily do that.
If they really need to get a version resource, so be it - they
should all be version 1.0, and InternalName "we just included
a version resource so that Microsoft's branding is happy".
Regards,
Martin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python for windows.
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 6.0, which isn't > even capable of dealing with manifests. > > Would it help compliance if we renamed them into .dat, so that the > conformance test doesn't recognize them as .exe files? That is probably a good idea regardless of the outcome of this discussion. Cheers, Mark ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python for windows.
> 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 never advise such people to install the python.org installer and have
> their application use Python from that directory.
I disagree. While it might not be really necessary for HP to have Python
comply to a formal test suite, I'm sure other users do need to pass
these test suites for whatever reason, and they are unhappy if they
don't pass out of the box.
Cleary, "we" (python-dev) would never run any of these test suites; it's
to much effort to buy them, run them, and study the results. So I'm
really glad HP spends the time on that stuff - not because HP needs it,
but because "smaller" users might run into it, and then frustrate
because they can't resolve the issues (rather than contacting us).
> These are stubs for installers. It is the installers created from these
> stubs that need the manifest, as the manifest requirements will differ for
> each use of the stub.
See my other message. This "obviously" comes from a formal test suite.
So it's not necessary to convince the operator of the test suite that
the test is flawed, but to convince the test suite to look elsewhere.
I think we can do that.
> Ditto for python.exe etc - its impossible to add a reasonable manifest, as
> the manifest requirements would depend entirely on what the python program
> itself does. There is no way python.exe can know what it will be asked to
> do.
FWIW, python.exe *does* have a manifest. The manifest is primarily about
static linking. I don't know what other uses a manifest may have, but if
it makes the test suite happy that python.exe has a manifest, then I'm
happy myself also.
> See above - we don't know ahead of time what an appropriate manifest is. I
> agree manifests need thought and work for Python, but I'm fairly sure the
> answer isn't to try and come up with them ahead of time and assume they
> apply universally.
Can you please elaborate? What specific elements of the manifest are you
thinking of that are not universally correct for python.exe?
>> - This c:\windows\installer\{110eb5c4-e995-4cfb-ab80-
>> a5f315bea9e8}\python_icon.exe do not answers to the Restart Manager
>> Aware
>
> That sounds like something nice to have, but assuming we recommend against
> using the standard Python installer for 3rd party applications, this is a
> problem for the application installer, not ours. In other words, I'm sure
> we'd welcome a fix to this, but I'd still recommend against using our
> installer anyway!
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. Of course, anybody embedding Python
*should* integrate it into his own application and installation
procedure. If we really want this guideline to be followed, we should
document explicitly how one does that (and no, pointing people to py2exe
is not sufficient).
> Maybe your and others lives would be made easier if the Python MSI installer
> was split up to support "merge modules"? That way you could roll your own
> installer that met any guidelines or requirements that mattered to you,
> while still ensuring you got all the files that the official installer would
> have installed. I'm hand-waving a little here, but it sounds like we can do
> more to help *others* meet guidelines for their Python based apps instead of
> trying and meet it for our installer...
If this list of complaints was complete, I don't find it too difficult
to comply. If a merge module would contain the entire library (including
distutils), then the wininst.exe issue would still exist for the merge
module (for example).
OTOH, if somebody wanted to contribute a procedure that builds merge
modules (in whatever granularity) along with the msi file - that would
also be appreciated.
Regards,
Martin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] 2.6.1 and 3.0
> Merge Modules into your installation > Create self-contained MSI packages, by including and configuring the > required merge modules. Right. Still, if people want to go this route (I personally don't), I think it would be useful to build an installer from the free edition. You can then run Tools/msi/merge.py, which adds the CRT merge module into the MSI file (mostly as-is, except for discarding the ALLUSERS property from that merge module). Alternatively, for testing, you can just assume that the CRT is already installed. When we then have a script that generates a mostly-complete installer, I'm sure Giovanni would be happy to add support for the CRT merge module to see how the tool fares (my expectation is that it breaks, as I assume it just doesn't deal with the embedded ALLUSERS property correctly - merge.py really uses a bad hack here). Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] 2.6.1 and 3.0
On mer, 2008-11-26 at 23:38 +0100, "Martin v. Löwis" wrote: > > Merge Modules into your installation > > Create self-contained MSI packages, by including and configuring the > > required merge modules. > > Right. Still, if people want to go this route (I personally don't), > I think it would be useful to build an installer from the free edition. > You can then run Tools/msi/merge.py, which adds the CRT merge module > into the MSI file (mostly as-is, except for discarding the ALLUSERS > property from that merge module). Alternatively, for testing, you can > just assume that the CRT is already installed. So, deducing from your reply, this "merge module" is a thing that allows to install the CRT (and other shared components)? I quickly googled but I'm not really into the msi slang, so I'm not sure I understood. > When we then have a script that generates a mostly-complete installer, > I'm sure Giovanni would be happy to add support for the CRT merge > module to see how the tool fares (my expectation is that it breaks, > as I assume it just doesn't deal with the embedded ALLUSERS property > correctly - merge.py really uses a bad hack here). Another option is to contact the Advanced Installer vendor and ask for a free license for the Python Software Foundation. This would mean that everybody in the world would still be able to build an installer without CRT, and only PSF would build the official one with CRT bundled. I personally don't see this as a show-stopper (does anyone ever build the .msi besides Martin?). -- Giovanni Bajo Develer S.r.l. http://www.develer.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] 2.6.1 and 3.0
On mer, 2008-11-26 at 22:54 +0100, "Martin v. Löwis" wrote: > > I've had good results with Advanced Installer: > > http://www.advancedinstaller.com/feats-list.html > > So how much effort would it be to create a Python installer? > Could you kindly provide one? In my case, the biggest effort would be finding out what needs to be put within the installer. If you can give me a pointer to where the current build process reads the complete file list to put within the .msi (and their relative destination path), I can try and build a simple test installer, on which we can start doing some evaluations. -- Giovanni Bajo Develer S.r.l. http://www.develer.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python for windows.
Gerald, if there is an expectation some of your HP windows users would like to use OpenSSL with Python, there is this little matter of including applink.c in the build. 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. ??? Larry [snip] Message: 2 Date: Wed, 26 Nov 2008 19:06:44 + From: "Koenig, Gerald" <[EMAIL PROTECTED]> Subject: [Python-Dev] Python for windows. To: "[email protected]" Message-ID: <[EMAIL PROTECTED] net> Content-Type: text/plain; charset="us-ascii" 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 contact to be able to work on that issue together ? The issue is about some requirement I need to have on our systems and even tools need to pass those requirement. Regards Gerald Koenig Software Builds Architect Hewlett-Packard Work Phone: +(1) 408 873 6202 -- [snip] ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] building Tcl/Tk to deploy on other platforms?
I built Python 2.5.2 on RedHat3 and wrapped it up with some other stuff that was deployed on RedHat4. When trying to fire up Idle on RedHat4, there is an error that states a usable init.tcl cannot be found. Python is built on RedHat3 against Tcl/Tk 8.3, so even installing Tcl/Tk on RedHat4 would not work, as it is 8.4. I've noticed when Python is installed on Windows, all the necessary stuff is also installed in the Python25 directory. Is there a similar way to do this on linux? Thanks, -Chris ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python for windows.
> > 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 never advise such people to install the python.org installer and > have > > their application use Python from that directory. > > I disagree. While it might not be really necessary for HP to have > Python > comply to a formal test suite, I'm sure other users do need to pass > these test suites for whatever reason, and they are unhappy if they > don't pass out of the box. 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 their application, as it exposes the ability for the user to remove it, thereby breaking the application. I would recommend that the application vendor take full control of the Python they rely on and install a "private" copy (either in their own directory or in a directory named other than "Python X.X".) In other words, I'm all for helping application vendors in every way to have their installers meet such guidelines, but I see having the Python installer itself meet such guidelines as effectively pointless as no one would actually need it. Obviously I'm wrong here though - HP obviously *is* wanting to install it as is, and doesn't mind that the user could accidently break their scripts. I'm very surprised by that, but I have to accept it :) On the other hand, I'd really like to ensure they understand the risks and for me to understand why those risks are acceptable... > > Ditto for python.exe etc - its impossible to add a reasonable > manifest, as > > the manifest requirements would depend entirely on what the python > program > > itself does. There is no way python.exe can know what it will be > asked to > > do. > > FWIW, python.exe *does* have a manifest. The manifest is primarily > about static linking. I don't know what other uses a manifest may have, The issue is regarding the Vista "user access control" flags, but yes, I see that python.exe does include a UAC entry in its manifest. As I mentioned, it will obviously not be approriate for all Python apps, but it is there and that is what matters for this discussion. > Can you please elaborate? What specific elements of the manifest are > you thinking of that are not universally correct for python.exe? A specific Python script may need a different UAC flag to work correctly in all cases - specifically one that requires elevation. If the manifest was appropriate for that script Windows would automatically elevate, but as things stand, the user would need to manually elevate before executing that script. > 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. Agreed. I'm just surprised app authors are willing to take the risk this implies. I still occasionally get email from people (presumably via my email addy which used to be in Pythonwin) saying "I've got this Python thing installed on my PC - is it a virus? Can I remove it?". I tend to say "its a programming language - if you don't know you need it, you probably don't, so sure, uninstall it". > Of course, anybody embedding > Python > *should* integrate it into his own application and installation > procedure. If we really want this guideline to be followed, we should > document explicitly how one does that (and no, pointing people to > py2exe is not sufficient). Actually, I don't think its that hard. Just plonk what you need (or *everything* except what you know you don't need, eg docs) in the same directory structure, test, rinse and repeat. Ideally you would also tweak the resource in pythonxx.dll which tells it the registry key to use too. If you had special UAC requirements you might even make a copy of python.exe which is identical except for the manifest, but now we are starting to get into app specific requirements... Cheers, Mark ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python for windows.
Hi all, Yes we spend the time and resources to do those tests. You do not have to worry about that :) and We will submit to Microsoft instead of you like that you do not have to worry about it. Microsoft is totally fine with it. I already asked them if it was fine. Unless you do not want us to do it. We do it for 2 reasons: We are trying to have all our systems OEM ready Compliant. Second all our customers will not have to worry about it, as it is already passing. I can promise you Python on our system Python work perfectly. We use it very often as our main scripting/programming tool like some other would use jscript or C#. We also follow your license agreement to never change anything from the packages. That why I went to this development board to see if some change can be done to make it OEM ready :) I didn't want to change anything by myself. So out of the three issue: - The three executable could be change to .dat ? - So if I understand well python_icon.exe is only stocking all the icon for python ? - I just checked for the version number it is not required expect for the uninstalled key which is already 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; [email protected] Subject: Re: [Python-Dev] Python for windows. > 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 never advise such people to install the python.org installer and have > their application use Python from that directory. I disagree. While it might not be really necessary for HP to have Python comply to a formal test suite, I'm sure other users do need to pass these test suites for whatever reason, and they are unhappy if they don't pass out of the box. Cleary, "we" (python-dev) would never run any of these test suites; it's to much effort to buy them, run them, and study the results. So I'm really glad HP spends the time on that stuff - not because HP needs it, but because "smaller" users might run into it, and then frustrate because they can't resolve the issues (rather than contacting us). > These are stubs for installers. It is the installers created from these > stubs that need the manifest, as the manifest requirements will differ for > each use of the stub. See my other message. This "obviously" comes from a formal test suite. So it's not necessary to convince the operator of the test suite that the test is flawed, but to convince the test suite to look elsewhere. I think we can do that. > Ditto for python.exe etc - its impossible to add a reasonable manifest, as > the manifest requirements would depend entirely on what the python program > itself does. There is no way python.exe can know what it will be asked to > do. FWIW, python.exe *does* have a manifest. The manifest is primarily about static linking. I don't know what other uses a manifest may have, but if it makes the test suite happy that python.exe has a manifest, then I'm happy myself also. > See above - we don't know ahead of time what an appropriate manifest is. I > agree manifests need thought and work for Python, but I'm fairly sure the > answer isn't to try and come up with them ahead of time and assume they > apply universally. Can you please elaborate? What specific elements of the manifest are you thinking of that are not universally correct for python.exe? >> - This c:\windows\installer\{110eb5c4-e995-4cfb-ab80- >> a5f315bea9e8}\python_icon.exe do not answers to the Restart Manager >> Aware > > That sounds like something nice to have, but assuming we recommend against > using the standard Python installer for 3rd party applications, this is a > problem for the application installer, not ours. In other words, I'm sure > we'd welcome a fix to this, but I'd still recommend against using our > installer anyway! 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. Of course, anybody embedding Python *should* integrate it into his own application and installation procedure. If we really want this guideline to be followed, we should document explicitly how one does that (and no, pointing people to py2exe is not sufficient). > Maybe your and others lives would be made easier if the Python MSI installer > was split up to support "merge modules"? That way you could roll your own > installer that met any guidelines or requirements that mattered to you, > while still ensuring you got all the files that the official installer would > have installed. I'm hand-waving a little here, but it sou
[Python-Dev] Module/Setup.dist maintainance
I was experimenting with profiled builds and building more extensions as builtins instead of loadable modules, noticing that Module/Setup.dist is not kept updated. Currently only the section above the *shared* line is really used for the build, but everything else doesn't seem to be updated (extensions are missing or out of date). Is there another way to build extensions as builtins, or should this file kept be up to date? Matthias ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] building Tcl/Tk to deploy on other platforms?
On Wed, Nov 26, 2008 at 8:42 PM, chris <[EMAIL PROTECTED]> wrote: > I built Python 2.5.2 on RedHat3 and wrapped it up with some other > stuff that was deployed on RedHat4. When trying to fire up Idle on > RedHat4, there is an error that states a usable init.tcl cannot be > found. > Then you have to set the TCL_LIBRARY environment variable, it should point to the directory that contains the correct init.tcl file. If it then complains about not finding tk.tcl, then you have to set the TK_LIBRARY env var too. > Python is built on RedHat3 against Tcl/Tk 8.3, so even installing > Tcl/Tk on RedHat4 would not work, as it is 8.4. > > I've noticed when Python is installed on Windows, all the necessary > stuff is also installed in the Python25 directory. Is there a similar > way to do this on linux? > Adjust the TCL_LIBRARY and TK_LIBRARY as needed. > Thanks, > -Chris > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/ggpolo%40gmail.com > -- -- Guilherme H. Polo Goncalves ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python for windows.
> 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 with a relatively easy solution? > very often as our main scripting/programming tool like some other would > use jscript or C#. Yes, but apps written in jscript and C# tend not to rely on something external, out of their control, that the user may remove. Even for apps written in C which rely on the C runtime library, the advice is still to ship a private copy of that CRT. OTOH, I guess some .NET apps *do* fall into this category... > So out of the three issue: > > - The three executable could be change to .dat ? I think that should be quite easy to do - I'll volunteer for this one (but not for a few days) > > - So if I understand well python_icon.exe is only stocking all > the icon for python ? I'm not familiar with that. > - I just checked for the version number it is not required > expect for the uninstalled key which is already clean. So to be clear, you don't desire any changes here? BTW - isn't there also a "\Program Files" requirement...? Cheers, Mark ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] 2.6.1 and 3.0
> So, deducing from your reply, this "merge module" is a thing that allows > to install the CRT (and other shared components)? Correct. More generally, a merge module is a something like an MSI library (.a). It includes a set of files and snippets of an installation procedure for them. > Another option is to contact the Advanced Installer vendor and ask for a > free license for the Python Software Foundation. This would mean that > everybody in the world would still be able to build an installer without > CRT, and only PSF would build the official one with CRT bundled. I > personally don't see this as a show-stopper (does anyone ever build > the .msi besides Martin?). I personally don't have any interest to spend any time on an alternative technology. The current technology works fine for me, and I understand it fully. Everybody in the world is able to build an installer today, also. However, I won't stop anybody else from working a switch to a different technology, either. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Fwd: distutils doesn't use some compiler options when building
I didn't know distutils has its own list. Forwarding. -- Forwarded message -- From: Akira Kitada Date: Thu, Nov 27, 2008 at 2:28 AM Subject: distutils doesn't use some compiler options when building To: [email protected] Hi, I encountered a weird problem using distutils. Generally, distutils try to use the same compiler options used for building Python interpreter, but it looks like some of them are omitted sometimes. - CPPFLAGS are not retrieved from the config and only ones in env are used. - OPT is retrieved from the config, but it's only used when env has CFLAGS. See: http://svn.python.org/view/python/trunk/Lib/distutils/sysconfig.py """ def customize_compiler(compiler): ... if compiler.compiler_type == "unix": (cc, cxx, opt, cflags, ccshared, ldshared, so_ext) = \ get_config_vars('CC', 'CXX', 'OPT', 'CFLAGS', 'CCSHARED', 'LDSHARED', 'SO') if 'CC' in os.environ: cc = os.environ['CC'] if 'CXX' in os.environ: cxx = os.environ['CXX'] if 'LDSHARED' in os.environ: ldshared = os.environ['LDSHARED'] if 'CPP' in os.environ: cpp = os.environ['CPP'] else: cpp = cc + " -E" # not always if 'LDFLAGS' in os.environ: ldshared = ldshared + ' ' + os.environ['LDFLAGS'] if 'CFLAGS' in os.environ: cflags = opt + ' ' + os.environ['CFLAGS'] ldshared = ldshared + ' ' + os.environ['CFLAGS'] if 'CPPFLAGS' in os.environ: cpp = cpp + ' ' + os.environ['CPPFLAGS'] cflags = cflags + ' ' + os.environ['CPPFLAGS'] ldshared = ldshared + ' ' + os.environ['CPPFLAGS'] cc_cmd = cc + ' ' + cflags compiler.set_executables( preprocessor=cpp, compiler=cc_cmd, compiler_so=cc_cmd + ' ' + ccshared, compiler_cxx=cxx, linker_so=ldshared, linker_exe=cc) compiler.shared_lib_extension = so_ext """ Are these logics are intentional or just a bug? If this is intentional behavior, why is that being this way? Thanks, ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python for windows.
> 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 their > application, as it exposes the ability for the user to remove it, thereby > breaking the application. 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. Python has been shipping as part of the operating system on Linux for many years now, and ships with Solaris and OSX for several years now. I see nothing wrong with Python being preinstalled on PCs. If this approach would become standard practice, py2exe and friends would become much simpler (and I do know that I'm dreaming now). > Obviously I'm wrong here though - HP obviously *is* wanting to install it as > is, and doesn't mind that the user could accidently break their scripts. > I'm very surprised by that, but I have to accept it :) On the other hand, > I'd really like to ensure they understand the risks and for me to understand > why those risks are acceptable... See above. I think the risk is theoretical. In any case, applications *can* make sure pythonxy.dll survives uninstallation (by increasing its refcount), although this probably doesn't help much if the standard library is gone. > Agreed. I'm just surprised app authors are willing to take the risk this > implies. I still occasionally get email from people (presumably via my > email addy which used to be in Pythonwin) saying "I've got this Python thing > installed on my PC - is it a virus? Can I remove it?". I tend to say "it’s > a programming language - if you don't know you need it, you probably don't, > so sure, uninstall it". We get these messages on python-help also. We even have http://www.python.org/doc/faq/installed/ so it *is* a frequently-asked question. I think that is a good thing. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] 2.6.1 and 3.0
> In my case, the biggest effort would be finding out what needs to be put > within the installer. If you can give me a pointer to where the current > build process reads the complete file list to put within the .msi (and > their relative destination path), I can try and build a simple test > installer, on which we can start doing some evaluations. The simplest approach might be to look at what it actually installs. If you want to read the specifcation: it's in Tools/msi/msi.py:add_files. directory.add_file takes a file, and optionally a source file (which defaults to the respective source directory). You also need to consider the features structure; there is a "current" feature at any point in time, and all components being added get added to the current feature. HTH, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python for windows.
> 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 in the past, but then I have forgotten since). Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] building Tcl/Tk to deploy on other platforms?
> Adjust the TCL_LIBRARY and TK_LIBRARY as needed. We should also point out that the FixTk module already does that, but is imported only on Windows. So if you arrange to always import FixTk, then it should Just Work. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Module/Setup.dist maintainance
Matthias Klose wrote: > Is there another way to build extensions as builtins, > or should this file kept be up to date? It should be kept up-to-date, IMO. It's just that people forget to do that (or don't even know what it is). Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] building Tcl/Tk to deploy on other platforms?
This may work on the deployed side, although I'm skeptical if I've built against a different version of Tcl/Tk than exists. I don't see how this helps on the build side, althought I'll look into it. On Wed, Nov 26, 2008 at 5:51 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: >> Adjust the TCL_LIBRARY and TK_LIBRARY as needed. > > We should also point out that the FixTk module already does > that, but is imported only on Windows. So if you arrange to > always import FixTk, then it should Just Work. > > Regards, > Martin > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] building Tcl/Tk to deploy on other platforms?
On Wed, Nov 26, 2008 at 9:51 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: >> Adjust the TCL_LIBRARY and TK_LIBRARY as needed. > > We should also point out that the FixTk module already does > that, but is imported only on Windows. So if you arrange to > always import FixTk, then it should Just Work. > It would Just Work if you had python and tcl/tk installed with the same paths as the ones used by the windows installer. > Regards, > Martin > -- -- Guilherme H. Polo Goncalves ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python for windows.
> > 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 in the past, but then I have > forgotten since). Yeah, it's been a while for me too. 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. >From http://www.openssl.org/docs/crypto/OPENSSL_Applink.html: OPENSSL_Applink is application-side interface which provides a glue between OpenSSL BIO layer and Win32 compiler run-time environment. Even though it appears at application side, it's essentially OpenSSL private interface. For this reason application developers are not expected to implement it, but to compile provided module with compiler of their choice and link it into the target application. The referred module is available as /ms/applink.c. 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 cannot import M2Crypto, pyOpenSSL, or use ctypes to wrap OpenSSL, and write a PEM file without throwing an error. (That said, Daniel Clark says he is not experiencing problems with NCrypt. I have not verified.) One solution is for those users to build their own Python from scratch. Many/most cannot do it, especially if they don't have the right version of Visual Studio. I know I don't. I simply stopped developing on Windows. Arguably better is to have the include statement in the python source file, python.c, appropriately conditioned. ...and to provide a copy of applink.c. That way, there would be no more need to try to find or do a custom build. Everybody building for a Windows platform will have applink included and access to OpenSSL becomes a non-issue. Larry ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python for windows.
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 from time to time on the mac-python mailing list. Personally, I always come down on the side of using the "system python", instead of installing a newer or different version. If, of course, it's sufficient for your application, and my experience is that it usually is. Bill ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 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 cannot import M2Crypto, pyOpenSSL, or use ctypes to wrap > OpenSSL, and write a PEM file without throwing an error. (That said, Daniel > Clark says he is not experiencing problems with NCrypt. I have not verified.) I'm probably missing something here. Python 2.6/3.x uses OpenSSL for the hashlib and ssl modules. Doesn't this mean that this applink.c file is part of the standard build now? Bill ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python for windows.
> 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 think we have ever agreed so much Martin :) Most of the issues discussed so far don't bother us at all, but in the back of my mind has always been what would happen if an "OEM Ready" guideline conflicts with what we would otherwise choose to do. FYI, I'm looking at google's HTML version of the MS doc via googling '"oem ready program" filetype:docx' and hitting the "view as HTML" link. 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. An interesting question we might need to face is exactly how much being "OEM Ready" is worth to Python itself if it requires us to make compromises we wouldn't otherwise make. But given Gerald hasn't mentioned this requirement, I must acknowledge it is still only a theoretical concern. However, should such a situation arise, my position would probably be that unless it was MS suggesting it be preloaded on *all* PCs, we should sacrifice that part of being "OEM Ready" to best look after the interests of people who seek it out for download. Cheers, Mark ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python for windows.
Not necessarily. I have no problems with hashlib or Python/M2Crypto/OpenSSL as long as I'm doing memory-oriented operations. It is only when the function does I/O that errors occur. ...like reading/writing a PEM file, randpool.dat, etc. -Original Message- From: Bill Janssen [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 26, 2008 5:54 PM To: Bugbee, Larry Cc: "Martin v. Löwis"; Koenig, Gerald; [email protected] 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 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 cannot import M2Crypto, > pyOpenSSL, or use ctypes to wrap OpenSSL, and write a PEM file without > throwing an error. (That said, Daniel Clark says he is not > experiencing problems with NCrypt. I have not verified.) I'm probably missing something here. Python 2.6/3.x uses OpenSSL for the hashlib and ssl modules. Doesn't this mean that this applink.c file is part of the standard build now? Bill ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python for windows.
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 can override the default if they wish. The current Python installers are unusual for Windows in having the default be anything else. I personally am now putting Python in /Programs along with other development tools whose directory tree I need to access, so it matters not to me. If HP is happy with stock installs after 10 years, they must not have a severe problem with uninstalls. The one suggestion I have for HP, now that we have a reps attention, is that they add a README.txt file to the Python directory that explains what is it, why it should not be uninstalled, and where to get more info about how the user can use this bonus feature of having bought an HP machine ;-). Terry ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] building Tcl/Tk to deploy on other platforms?
> It would Just Work if you had python and tcl/tk installed with the > same paths as the ones used by the windows installer. Right - the OP will probably need to supply a different version of FixTk also. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python for windows.
> 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 explains what it is. > Arguably better is to have the include statement in the python source > file, python.c, appropriately conditioned. ...and to provide a copy > of applink.c. That way, there would be no more need to try to find > or do a custom build. Everybody building for a Windows platform will > have applink included and access to OpenSSL becomes a non-issue. However, this doesn't explain why I should care about it. What is the problem that is being solved for Python? Why is access to OpenSSL an issue currently? Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python for windows.
> 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 files, and while there is occasional breakage, we do want to support this case - just not make it the default. > However, should such a situation arise, my position would probably be that > unless it was MS suggesting it be preloaded on *all* PCs, we should > sacrifice that part of being "OEM Ready" to best look after the interests of > people who seek it out for download. So much agreement :-) Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
