[issue4709] Mingw-w64 and python on windows x64
cournapeau david courn...@gmail.com added the comment: Hi Martin, It was nice meeting you at Pycon. I finally took the time to set up a windows 64 bits environment, and here are the exact steps I needed to do to reproduce the issue, and fix it by hand: - Start fresh from windows 7 64 bits - clone python hg repository, and checkout the 2.6 branch (path referred as $PYTHON_ROOT from now on). - build python with VS 2008 pro, 64 bits (release mode) - install mingw-w64. I used this exact version: mingw-w64-1.0-bin_i686-mingw_20110328.zip (release 1.0, targetting win64 but running in 32 bits native mode), and unzipped it in C:¥ - I compiled a trivial C extension in foo.c as follows: C:\mingw-w64\bin\x86_64-w64-mingw32-gcc.exe foo.c -I $PYTHON_ROOT\Include -I $PYTHON_ROOT\PC -shared -o foo.pyd $PYTHON_ROOT\PCbuild\amd64\python26.lib -DMS_WIN64 The patch removes the need for defining MS_WIN64. I don't know exactly the policies for which branch this could be applied - anything below 2.6 does not make much sense since most win64 users use 2.6 at least. Ideally, it could be backported to 2.6, 2.7 and 3.1 ? -- nosy: +cournape ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4709 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11552] Confusing error message when hook module cannot be loaded
New submission from cournapeau david courn...@gmail.com: The following simple example: setup.cfg [global] setup_hook = hooks.foo and the following hooks.py file def foo(content): pass Traceback (most recent call last): File ../distutils2/distutils2/pysetup, line 5, in module main() File /Users/david/src/projects/distutils2/distutils2/run.py, line 486, in main return dispatcher() File /Users/david/src/projects/distutils2/distutils2/run.py, line 477, in __call__ return func(self, self.args) File /Users/david/src/projects/distutils2/distutils2/run.py, line 161, in _run dist.parse_config_files() File /Users/david/src/projects/distutils2/distutils2/dist.py, line 317, in parse_config_files return self.config.parse_config_files(filenames) File /Users/david/src/projects/distutils2/distutils2/config.py, line 258, in parse_config_files self._read_setup_cfg(parser, filename) File /Users/david/src/projects/distutils2/distutils2/config.py, line 120, in _read_setup_cfg self.setup_hook = resolve_name(setup_hook) File /Users/david/src/projects/distutils2/distutils2/util.py, line 644, in resolve_name raise ImportError(exc) ImportError: 'str' object has no attribute 'foo' I don't understand how it works exactly, but the current code cannot work, as ret needs to be a module package after the __import__ (i.e. the codepath following line 632 and later in util.py (resolve_name function)) -- assignee: tarek components: Distutils2 messages: 130958 nosy: alexis, cournape, eric.araujo, tarek priority: normal severity: normal status: open title: Confusing error message when hook module cannot be loaded type: crash ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11552 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6039] cygwin compilers should not check compiler versions
New submission from Cournapeau David da...@ar.media.kyoto-u.ac.jp: cygwin compiler modules in distutils check versions of the toolchain, and break is the version is not a released one. I can't see the rationale for such a behavior, and it is particularly annoying since it cannot be bypassed AFAIK. As it is the only toolchain to use those version checks, I suggest to just remove them. This affects every python version from 2.4 to 2.6, and possibly the 3.* versions as well. -- assignee: tarek components: Distutils messages: 87876 nosy: cdavid, tarek severity: normal status: open title: cygwin compilers should not check compiler versions ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6039 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6040] bdist_msi does not deal with pre-release version
New submission from Cournapeau David da...@ar.media.kyoto-u.ac.jp: If bdist_msi is used on a package which has a non released version (defined from StrictVersion), it refuses to build the package. The code for the bdist_msi mentions that pre-release is not supported. Knowing nothing about msi, I don't know what shall be done for it to work. -- messages: 87877 nosy: cdavid severity: normal status: open title: bdist_msi does not deal with pre-release version versions: Python 2.4, Python 2.5, Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6040 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5941] customize_compiler broken
Cournapeau David da...@ar.media.kyoto-u.ac.jp added the comment: Ok, here is a patch which fixes the issue while retaining the AR customization. Here is what it does: - configure defines both AR and ARFLAGS in the configure script, and those are used in the Makefile - ARFLAGS is used instead of the harcoded rc (rc is the default value for ARFLAGS in configure) - Both AR and ARFLAGS are used in customize_compiler in distutils. If any of them is customized from the environment, they are overriden. Some examples: - default: nothing changes, except that archiver is set to ar rc instead of ar in customize_compiler, thus build_clib is not broken anymore - setting AR/ARFLAGS in configure: those are used in the python build - ARFLAGS=cru python setup.py build_clib will use ar cru instead of ar cr for libraries. The only thing I am a bit unsure is that instead of ar -cr, we have ar cr used as archiver in distutils. Since ac cr is currently used in the python makefile, I guess most unixes understand ar cr, though. -- keywords: +patch Added file: http://bugs.python.org/file13911/bug_5941.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5941 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4709] Mingw-w64 and python on windows x64
Cournapeau David da...@ar.media.kyoto-u.ac.jp added the comment: Ok, it looks like following gcc 4.4.0 release, there is an installer for the whole toolchain: http://www.equation.com/servlet/equation.cmd?call=fortran This installs gcc (C+Fortran+C++ compilers, the download is ~ 40 Mb), and it can be used from the command line as conventional mingw32. Hopefully, this should make the patch much easier to test. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4709 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5941] customize_compiler broken
Cournapeau David da...@ar.media.kyoto-u.ac.jp added the comment: The bug is also present in python 2.7a -- versions: +Python 2.7, Python 3.0 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5941 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5941] customize_compiler broken
Cournapeau David da...@ar.media.kyoto-u.ac.jp added the comment: You can see the traceback in this recent email: http://mail.python.org/pipermail/python-list/2009-May/712106.html -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5941 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5940] Wrong type check in check_library_list
New submission from Cournapeau David da...@ar.media.kyoto-u.ac.jp: There is a bug in the function check_library_list. Assuming there are some libraries in the distribution instance, the function checks that lib[0] is a string, but the test checks exactly the contrary (line 137 of build_clib.py). This is pretty serious, as any code using libraries will fail to build on python3. The fix is trivial, though. I think this should be fixed for python 3.1 -- assignee: tarek components: Distutils messages: 87224 nosy: cdavid, tarek severity: normal status: open title: Wrong type check in check_library_list versions: Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5940 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5941] customize_compiler broken
New submission from Cournapeau David da...@ar.media.kyoto-u.ac.jp:
The customize_compiler function is broken in python 3.1. The archiver
for a 'standard' unix compiler is set as ['ar', '-cr'], but in python
3.*, customize_compiler overwrites self.archiver from
get_sysconfig_var('AR'), and AR is defined as ar, which breaks
create_static_library.
I think the solution is to define a new env variable AR_something or to
set AR to 'ar -rc' (like LDSHARED is set to ['gcc', '-shared'] on gnu
systems, for example).
--
assignee: tarek
components: Distutils
messages: 87231
nosy: cdavid, tarek
severity: normal
status: open
title: customize_compiler broken
versions: Python 3.1
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5941
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5941] customize_compiler broken
Cournapeau David da...@ar.media.kyoto-u.ac.jp added the comment:
Hi Tarek,
Yes, I have a simple example, which show both 5940 and 5941 bugs:
from distutils.core import setup
# How to install libfoo.a/foo.lib in say pkg_dir/lib ?
setup(name='yo', libraries=[('foo', {'sources': ['foo.c']})])
foo.c can be an empty file.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5941
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5941] customize_compiler broken
Cournapeau David da...@ar.media.kyoto-u.ac.jp added the comment: Both should be set as serious, in the sense that build_clib is totally broken ATM, with no simple workaround. OTOH, maybe numpy is the only user of build_clib, in which case it is not so serious (I use my own fixed, copied versions of the original code for the time being in numpy distutils extensions). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5941 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4709] Mingw-w64 and python on windows x64
Cournapeau David da...@ar.media.kyoto-u.ac.jp added the comment: The toolchain is difficult to build, but the patch is easy to review, it just moves the MS_WIN64 outside the MS compiler specific part. If it does not break the MS toolchain (the one used to build the official python), I don't see the problem. I can make the toolchain available to you as a tarball, though, so that you can easily test from a windows command shell without having to install anything. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4709 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2943] Distutils should generate a better error message when the SDK is not installed
Cournapeau David da...@ar.media.kyoto-u.ac.jp added the comment: Hi tarek, I can't say for sure about the only part. My experience on windows is that there are so many possible combinations that getting it right is difficult. But in any case, the raised exception is not helpful. I am a developer and familiar with distutils, and I could not make any sense of the message. If the cause cannot be determined, at least a message like Unexpected result while detecting MS toolchain (str(result) vs str(interesting) would be helpful I think. Also, but I am not 100 % sure about this, I believe any exception raised within distutils should be inherited from DistutilsError -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2943 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4709] Mingw-w64 and python on windows x64
Cournapeau David da...@ar.media.kyoto-u.ac.jp added the comment: Is there any change to see this integrated soon ? The patch is only a couple of lines long, thanks -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4709 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2121] complex constructor doesn't accept string with nan and inf
Cournapeau David da...@ar.media.kyoto-u.ac.jp added the comment:
@ Mark
Concerning float('inf') * 1j: you're right, my rambling did not make any
sense, sorry.
I agree that adding complexity may be a good reason to warrant an
arbitrary feature; actually, I did not manage to handle nan/inf at first
because of the complexity :) But as I mentioned in a previous comment, I
think my patch simplifies the parsing as well. I suggested to split the
patch in to: one whithout any new feature (no handling of nan/inf), and
then anoter handling nan/inf on the top of it. Would that be acceptable ?
Also, how should I proceed to share implementation between floatobject.c
and complexobject.c ? Would creating a new file for the common code be
acceptable ?
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2121
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2121] complex constructor doesn't accept string with nan and inf
Cournapeau David da...@ar.media.kyoto-u.ac.jp added the comment: It is not really for an application, but for numpy. Of course, one can always get around the problem - but since this is really a limitation which can be easily fixed, why not fixing the problem :) ? ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2121 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2121] complex constructor doesn't accept string with nan and inf
Cournapeau David da...@ar.media.kyoto-u.ac.jp added the comment: I disagree the feature is not needed, for several reasons: - complex(repr(..)) roundtrip should work, whatever the value of complex is - it is supported for float, so why not for complex ? - I believe on the contrary it solves a very real problem: incidently, I got interested in this patch while working on numpy, and it is certainly useful to be able to parse nan and inf (for example when we create arrays from strings). Nan may be seen as non useful for so called real usage of python, but for scientific people, it is a crucial to have proper support of nan (which may mean missing data depending on the context) and inf. - it does not add complexity: I would argue that independantly of nan/inf support, my patch makes the function simpler to follow (no state machine with done/sw_error/etc... state). ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2121 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2121] complex constructor doesn't accept string with nan and inf
Cournapeau David da...@ar.media.kyoto-u.ac.jp added the comment: Nice-to-have but not a requirement that the entire input domain be supported. Ok. It made sense for floats because of prevalence of use cases and because we wanted to match IEEE-754R as much as possible. But why shouldn't this apply to complex numbers ? I am biased because I mainly use python for scientific work, but complex numbers are not more special than float in my mind. Unfortunately, the support for Infs and NaNs has already negatively impacted the float world by making the math module harder to maintain and test. Yes, it is difficult to handle nan and inf, there are a lot of corner cases. But I fail to see how this applies here: my patch is essentially a rewrote of the parsing, and the code to handle nan/inf is only 7 lines. This is independent of the handling of how nan/inf is handled by math operations on it. Mark, does Inf have a standard interpretation for complex numbers? Do all infinities meet or do they radiate, each with their own phase angle? Hm, not sure what you mean here by standard interpretation, but infinities do not meet, in the sense that (x,inf) and (inf,x) for example can never been 'near' from each other (in the distance sense), except if x is inf. It does not make more sense to talk about phase of complex numbers with inf than for 0. But again, I don't see how this is relevant to the proposed feature. Mainly, I'm just questioning whether there exist compelling use cases for parsing NaNs and Infs in the context of complex numbers. For any task where parsing complex makes sense. Since many numerical operations may end up with nan or inf, this is relatively common I would say. It this can make the review easier, I can split the patch in two: first the refactoring (+ tests once someone tells me how to), and then inf/nan handling (with additional tests). ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2121 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2121] complex constructor doesn't accept string with nan and inf
Cournapeau David da...@ar.media.kyoto-u.ac.jp added the comment: Ok, I found out how to make tests, and I found some problems while using this on numpy. A third version of the patch, with unit tests: all tests in test_complex.py pass. Added file: http://bugs.python.org/file12504/nan_parse.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2121 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2121] complex constructor doesn't accept string with nan and inf
Changes by Cournapeau David da...@ar.media.kyoto-u.ac.jp: Removed file: http://bugs.python.org/file12503/nan_parse.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2121 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2121] complex constructor doesn't accept string with nan and inf
Changes by Cournapeau David da...@ar.media.kyoto-u.ac.jp: Removed file: http://bugs.python.org/file12502/nan_parse.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2121 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4799] handling inf/nan in '%f'
New submission from Cournapeau David da...@ar.media.kyoto-u.ac.jp:
On windows, with python 2.6, s = '%s' % float('inf') is 'inf', but s =
'%f' % float('inf') is equal to '1.#INF'.
This patch fixes the inconsistency, by using the code from floatobject.f
format_float into stringobject.c formatfloat. I think it would be better
to use the same underlying implementations for both functions, but it is
not so easy, because format_float cannot fail (return void), whereas
formatfloat can (return error code).
--
components: Interpreter Core
files: nan.patch
keywords: patch
messages: 78693
nosy: cdavid
severity: normal
status: open
title: handling inf/nan in '%f'
versions: Python 2.6
Added file: http://bugs.python.org/file12518/nan.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4799
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2121] complex constructor doesn't accept string with nan and inf
Cournapeau David da...@ar.media.kyoto-u.ac.jp added the comment: I started a patch against the trunk to handle nan/inf/infinite (I have not yet tackled the problem of negative zero). The patch is a bit big, because I found the function quite difficult to follow, so I refactored it a bit first (replacing the state machine with the big switch with a sequential parsing). One potential problem is that I do some computation with inf to make signed infinite, I don't know if it is safe. I don't know is setting a variable to Nan is safe either. Although I tested the function in a simple main under valgrind for various legit and bogus input, there is no tests in this patch. I would like to add some, but I am not familiar with python testing, so I would be glad to receive some indications on how to do it properly. -- keywords: +patch nosy: +cdavid Added file: http://bugs.python.org/file12502/nan_parse.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2121 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2121] complex constructor doesn't accept string with nan and inf
Cournapeau David da...@ar.media.kyoto-u.ac.jp added the comment: Of course, I notice two bugs just after sending the patch... New patch to fix those two issues (no check for closing bracket if opening ones are there and a bug when only imaginary part is given). Added file: http://bugs.python.org/file12503/nan_parse.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2121 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4728] Endianness and universal builds problems
New submission from Cournapeau David da...@ar.media.kyoto-u.ac.jp:
I had some problems with python and universal builds related to the
WORDS_BIGENDIAN macro. Because universal builds are built in one pass
(one configure), the AC_C_ENDIAN cannot be used reliably. Example:
int main()
{
#ifdef WORDS_BIGENDIAN
printf(Big endian macro defined\n);
#else
printf(No big endian macro defined\n);
#endif
return 0;
}
If I build this against python 2.5, it prints no big endian macro (I
have an intel CPU), as expected. But with python 2.6.0 (official binary
from python.org), I get Big endian macro defined.
--
messages: 78224
nosy: cdavid
severity: normal
status: open
title: Endianness and universal builds problems
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4728
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4709] Mingw-w64 and python on windows x64
New submission from Cournapeau David da...@ar.media.kyoto-u.ac.jp:
I believe the current pyport.h for windows x64 has some problems. It
does not work for compilers which are not MS ones, because building
against the official binary (python 2.6) relies on features which are
not enabled unless MS_WIN64 is defined, and the later is not defined if
an extension is not built with MS compiler.
As a simple example:
#include Python.h
int main()
{
printf(sizeof(Py_intptr_t) = %d\n, sizeof(Py_intptr_t));
return 0;
}
If you build this with MS compiler, you get the expected
sizeof(Py_intptr_t) = 8, but with gcc, you get 4. Now, if I build the
test like:
gcc -I C:\Python26\include -DMS_WIN64 main.c
Then I got 8 as well.
I believe the attached patch should fix the problem (I have not tested
it, since building python on amd64).
--
components: Build
files: mingw-w64.patch
keywords: patch
messages: 78140
nosy: cdavid
severity: normal
status: open
title: Mingw-w64 and python on windows x64
type: compile error
versions: Python 2.6
Added file: http://bugs.python.org/file12411/mingw-w64.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4709
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4365] Add CRT version info in msvcrt module
New submission from Cournapeau David [EMAIL PROTECTED]: This patch if the first part to follow discussion on python-list concerning problems when using distutils.config.try_run with mingw and manifest problems on windows for python 2.6 (or any python built with recent VS). It simply adds strings constant got the msvcrt module, so that they can be queried in distutils to generate manifest on the fly if needed. I don't know which approach is best to deal with conditional compilation: for now, I simply do not add the constants if the constants are not defined at the C level, but this does not strike as a great idea to me. -- components: Windows files: msvcrt_version_info.diff keywords: patch messages: 76112 nosy: cdavid severity: normal status: open title: Add CRT version info in msvcrt module versions: Python 2.7 Added file: http://bugs.python.org/file12074/msvcrt_version_info.diff ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4365 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2943] Distutils should generate a better error message when the SDK is not installed
New submission from Cournapeau David [EMAIL PROTECTED]: I tried to build some extensions with python 2.6 (built from sources with VS 2008 express), and got some errors in the function query_vcvarsall. The offending lines are: if len(result) != len(interesting): raise ValueError(str(list(result.keys( I got a value error here. After some investigation, I realized that it was because I did not install the SDK. I think the error message could be isgnificantly improved if installing the SDK was suggested in the exception message. -- components: Distutils messages: 67187 nosy: cdavid severity: normal status: open title: Distutils should generate a better error message when the SDK is not installed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2943 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2694] msilib file names check too strict ?
Cournapeau David [EMAIL PROTECTED] added the comment: Ok, thanks for the information. It may good to have a bit more informative error, though, such as saying which characters are allowed when checking against a regex ? __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2694 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2694] msilib file names check too strict ?
Cournapeau David [EMAIL PROTECTED] added the comment: It's not that I don't want to work on it, but I don't know anything about msi, except that some windows users of my packages request it :) So I would need some indication on what to fix exactly Do I understand right that dist_msi builds a database of the files, and that the identifiers could be named differently than the filenames themselves, as long as they are unique ? __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2694 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2694] msilib file names check too strict ?
New submission from Cournapeau David [EMAIL PROTECTED]: Hi, I wanted to build a msi using the build_msi distutils command for one of my package, but at some point, it fails, at the function make_id, at line 177 in mstlib/__init__.py, for a file named aixc++.py. The regex indeed refuses any character which is not alphanumeric: is msi itself really that strict, or could this check be relaxed ? -- components: Windows messages: 65834 nosy: cdavid severity: normal status: open title: msilib file names check too strict ? type: feature request versions: Python 2.5 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2694 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
