agree it's an awful idea. Older wininst installers such as
the pywin32 (and I think the PyQT one) one do this, I wanted to use it
as an example of abuse of postinstall scripts that should *not* be
perpetuated in any new scheme.
FWIW I've just had a to-and-fro by email with Mark Hammond. I gather
On 9/01/2012 9:10 AM, Almar Klein wrote:
Since there've been no responses yet, let me make my question more clear :)
Is this is a bug, or is this a known feature that I should solve in
another manner. If this is a bug, can someone help me fix it?
It probably can be considered a bug - the
On 4/11/2011 3:53 AM, Paul Moore wrote:
On 3 November 2011 16:45, Éric Araujomer...@netwok.org wrote:
I wouldn’t do that: It would trick Python into thinking it’s installed
without actually doing all the things that make it installed.
Agreed, it's not good. It's just that I don't know (on
On 29/05/2011 9:42 AM, James wrote:
I just tried to download and run the python2.5 0.6c11 setuptools and I
get a message that there is no record of python in the registry and the
install cannot proceed. Annoyingly there are two empty text boxes that
look like one might be able to type a path in
On 26/06/2010 7:29 PM, anatoly techtonik wrote:
Mark, can you compile a list of features and windows/python version
compatibility provided by each stub to evaluate what is the best stub
to use with pure Python modules?
As far as I know, the only issue you will find with ealier stubs is the
On 11/06/2010 6:43 PM, anatoly techtonik wrote:
On Mon, Jun 7, 2010 at 10:01 AM, Mark Hammondskippy.hamm...@gmail.com wrote:
build_wininst code [1] function get_exe_bytes() used to fetch
appropriate stub, doesn't seem to be cross-platform.
Sorry, I must have misunderstood the original
On 7/06/2010 1:16 AM, anatoly techtonik wrote:
While Trac 0.12 is about to be released, there is some uncertainty
whenever new Distutils-generated installers are compatible with old
versions of Windows and Python. There are some fears that installers
generated on Vista and Windows 7 won't run on
I hope the tracker can cope with these ad-hoc replies:
But there is just no way to install bdist_wininst created packages in
silent mode.
Sadly there is no way - but this is technically a limitation of distutils,
not setuptools. Patches would be accepted for this though, and please don't
be
Currently eggs created for amd64 platforms are called x86_64 in the egg
filename. AMD renamed x86_64 to amd64 and asked people to follow suit.
Also Python uses the amd64 nomenclature:
http://mail.python.org/pipermail/python-bugs-list/2006-
December/036400.html and
Hi all,
I've just added this patch which adds basic UAC support to bdist_wininst in a
fairly unobtrusive manner. I've added Thomas to the nosy list, but I'd welcome
any feedback or concerns from everyone.
Thanks,
Mark
-Original Message-
From: Mark Hammond [mailto:[EMAIL PROTECTED
As another alternative to providing a separate AMD64 binary, you could
also try to make the existing binary work properly on Win64, and tell
it with a config flag whether to look for Win32 or Win64 (or either)
on the target system.
I'm afraid that isn't an option for me in the short term.
As I was preparing to check-in my cross-compilation patch, which includes a
new x64 executable in the Lib/distutils/command directory, it occurs to me
that we don't actually need it in subversion - and nor do we need
wininst-9.0.exe.
I believe these executables are in svn for historical reasons.
I think this is fine; we don't really have a notion of compiling for a
native platform, nor is the build machine's architecture factored into
the equation.
Actually, I think it is slightly. IIUC, the AMD64 build currently assumes
it can execute x86 executables in various places. To fix this,
From: Dave Peterson [mailto:[EMAIL PROTECTED]
Sent: Wednesday, 2 April 2008 3:30 PM
Cc: Mark Hammond; distutils-sig
Subject: Re: [Distutils] [Python-Dev] How we can get rid of eggs for 2.6 and
beyond
Mark Hammond wrote:
(Note: I'm aware that people believe it to be necessary to munge
I wrote:
FYI, I've uploaded a patch that provides for cross-compilation on
Windows between 32 and 64 bit platforms - all comments invited!
While I have some people's attention I'd like to re-raise another issue I
foresee for x64 builds. I've mentioned this over the last couple of months,
but
Martin quoting me:
Currently, the official (by way of being de-facto) directory
structure for a build tree is 'PCBuild/.' for x86 builds and
'PCBuild/amd64' for x64
platforms. I believe this might cause problems for people trying to
port their applications to 64bit platforms. My
FYI, I've uploaded a patch that provides for cross-compilation on Windows
between 32 and 64 bit platforms - all comments invited!
Thanks,
Mark
-Original Message-
From: Mark Hammond [mailto:[EMAIL PROTECTED]
Sent: Sunday, 30 March 2008 6:01 PM
To: [EMAIL PROTECTED]
Subject: [issue2513
agreement on the compromise proposal I
outlined?
Thanks,
Mark
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of Mark Hammond
Sent: Tuesday, 22 January 2008 9:06 PM
To: 'Martin v. Löwis'
Cc: distutils-sig@python.org; [EMAIL PROTECTED]
Subject: Re
Hi Martin,
Way back on Monday, 21 May 2007, you wrote:
This is an issue to be discussed for Python 2.6. I'm personally
hesitant to have the official build infrastructure deviate
from the layout that has been in-use for so many years, as a lot
of things depend on it.
I don't find the
How does Python on Windows determine sys.prefix?
By consulting the registry. The main use-case for that is when Python is
embedded in another executable - often, but not always, via COM. When
Python is hosted inside excel.exe, for example, its impossible to calculate
sys.path or sys.prefix
I can certainly create a landmark if at all reasonable. I'm looking at
getpathp.c, and it looks like it just looks for lib/os.py ... and I
think it walks up from the current directory until it finds it? So
right now I have:
bin/python.exe
lib/python2.5/os.py
But perhaps if I
It is quite easy to use the bdist_wininst command to create a
Windows installer executable. A browser click on a link to
the .EXE file allows for software installation, but
easy_install is not run and the packages listed in
setup.install_requires are not installed. Is there a way to
http://en.wikipedia.org/wiki/X86-64 notes that 'x64' is a common
name, so
how does 'win-x64' and 'win-ia64' sound as a compromise?
I'm happy
to let
any other informal votes make a final decision though...
As one who is forever switching back and forth among operating
systems
Dave writes:
I could be mistaken, but I believe the standard abbreviations
for these
architectures are 'x86_64' (intel/amd chipset) and 'ia64'
(itanium) --
see the first two paragraphs of the wikipedia article on
Itanium for an
example:
http://en.wikipedia.org/wiki/Itanium
So how
Johan:
I'm having trouble using distutils with the bdist_wininst option.
I've been able to create a COM server and package it in a .DLL,
but I can't create an installer as a .exe My goal is to create
a .exe that can be run on a client machine that does NOT have the
standard Python
Many of the distutils commands use distutils.util.get_platform() as the
basis for file and directory names used to package up extensions. On
Windows, this returns the value of sys.platform. On all (desktop) Windows
versions, this currently returns 'win32'.
This causes a problem when trying to
Tres writes:
Mark Hammond wrote:
At 04:00 PM 7/18/2007 +1000, Mark Hammond wrote:
This will result in both the final version of most bdist_*
installations
having the architecture in the filename. It also has the
nice side effect
of having the temp directories used by these commands
Phillip writes:
Because distutils' get_platform() isn't really clear about the
distinctions that setuptools makes explicit, about version
compatibility. In a sense, distutils' get_platform assumes that no
platform can run any other platform's code, even though this isn't so
for at least Mac
That was based on presumption that wininst is superseded by msi, which is
clearly incorrect, as you've shown.
Well, all I really meant to say was that bdist_msi doesn't (yet) have all
the features of bdist_wininst - but bdist_msi does appear to be the future
(ie, there is not much interest on
Hi all,
I'm making good progress on using bdist_msi to package up x64 versions of
the pywin32 extensions. On the way I've struck a number of issues. In an
effort to try and keey the discussions focussed, I'll create new threads for
each of them, and the first cab off the rank is
Ah. Okay, first, pywin32 isn't registered on PyPI, so you need a -f
link to find the files:
easy_install -f
http://sourceforge.net/project/showfiles.php?group_id=78018 pywin32
This is easily fixed by adding a PyPI listing with the above URL
registered as the Download URL.
Cool -
Hi Jim,
Since you happen to be paying attention to distributions atm ... :)
I would love to see a pywin32 egg, which by definition, didn't need
to modify anything when it was installed. I guess there are some
features in pywin32 that wouldn't work with such a setup, but I'm
guessing that
Martin v. Löwis wrote:
I use this patch in ActivePython to get distutils to find
the correct
PCbuild dir (see attached).
Would you like to commit this to 2.6? (or perhaps 2.5 even?)
Sure, if others think it is a good thing. Will do tomorrow
unless I hear
a -1 before then.
I'm not
However, I think people ask much too often for a debugging build;
in many cases, they could work happily with a release build that
supports debugging. Depending on the problem you try to solve, you
may or may not need debug information for pythonxy.dll as well,
or just for your extension
Hi Martin,
You are likely doing something wrong:
a) I assume it's VS 7.1 (i.e. VS.NET 2003); VS 2002 is not supported
at all
b) you probably didn't install vsextcomp, but you should.
In fact, you don't need all of it, but you do need the cl.exe and
link.exe wrappers it comes with -
Hi Marc-Andre,
+1 from me.
If think this is simply a bug introduced with the UCS4 patches in
Python 2.2.
unicodeobject.h already has this code:
#ifndef PY_UNICODE_TYPE
/* Windows has a usable wchar_t type (unless we're using UCS-4) */
# if defined(MS_WIN32) Py_UNICODE_SIZE == 2
#
Hi all,
I hope the cross-post is appropriate.
I've started playing with getting the pywin32 extensions building under
the AMD64 architecture. I started building with Visual Studio 8 (it was
what I had handy) and I struck a few issues relating to the compiler version
that I thought worth
37 matches
Mail list logo
