Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
The following modules appear to be missing ['_sysconfigdata']
189 views
Skip to first unread message
dude....@gmail.com
Jan 8, 2019, 5:38:29 AM1/8/19
to
Hello,
first time using python groups (and long time since using any other group for that matter). This might not be the right group due to wx being involved.
Long story as short as possible. I have an old python script that I did ~10 years ago, and have forgotten basically everything about Python since then (sorry!). Converted it to EXE way back when, and have kept using the EXE ever since then (on XP, and on Win7).
I've just gotten a new PC, Windows10 (!), needed to update the script, so needed to recompile the EXE, and now it no longer compiles/works. It was fine on Windows7 (I'm not specifically stating that the problem is with windows10 - I simply don't remember all the hoops I jumped through on my previous machine).
Here is the compile error:
The following modules appear to be missing
['_sysconfigdata']
And here is the runtime error:
Traceback (most recent call last):
File "AutoArchive.py", line 3, in <module>
File "wx\__init__.pyc", line 45, in <module>
File "wx\_core.pyc", line 4, in <module>
File "wx\_core_.pyc", line 12, in <module>
File "wx\_core_.pyc", line 10, in __load
ImportError: DLL load failed: %1 is not a valid Win32 application.
Here is how I compile: python setup.py py2exe
And this is my setup.py:
from distutils.core import setup
import py2exe
setup(console=['AutoArchive.py'])
Yes, that says 'console' for a Windows EXE, but swapping it to 'window' didn't help. Besides which, the setup.py file is straight from the old computer, so 'it used to work'.
What I have installed:
. python 2.7.13 (this in itself may be a problem - I don't even remember which version I was using earlier, other than knowing for sure it wasn't a 3.x release)
. wxpython (since I also got an error that wx module was missing - that rang some bells, since the script uses a Windows pop-up window to inform me about its progress, and I remember using wx for that, so I installed it, but don't know how to get its' version. using "python -c "import wx;print wx.__version__" just gives runtime errors).
Any help would be appreciated.
And yes, I googled, but can't really find anything (well, d'Uh!, I wouldn’t be here then would I?) - there's ~some~ references, but usually it's about similar issues on Linux, with solutions that are not applicable at all. Except one I thought: I found some link stating that _sysconfigdata is part of sysconfig, and that this needed to be installed with pip, so I used the pip that came with my python distro and did 'pip install [[_]sys]config[data]' (all possible combo's) but pip claims it can't find said module, and TBH, I can't seem to find anything myself about said module.
Thx,
Jimbo
first time using python groups (and long time since using any other group for that matter). This might not be the right group due to wx being involved.
Long story as short as possible. I have an old python script that I did ~10 years ago, and have forgotten basically everything about Python since then (sorry!). Converted it to EXE way back when, and have kept using the EXE ever since then (on XP, and on Win7).
I've just gotten a new PC, Windows10 (!), needed to update the script, so needed to recompile the EXE, and now it no longer compiles/works. It was fine on Windows7 (I'm not specifically stating that the problem is with windows10 - I simply don't remember all the hoops I jumped through on my previous machine).
Here is the compile error:
The following modules appear to be missing
['_sysconfigdata']
And here is the runtime error:
Traceback (most recent call last):
File "AutoArchive.py", line 3, in <module>
File "wx\__init__.pyc", line 45, in <module>
File "wx\_core.pyc", line 4, in <module>
File "wx\_core_.pyc", line 12, in <module>
File "wx\_core_.pyc", line 10, in __load
ImportError: DLL load failed: %1 is not a valid Win32 application.
Here is how I compile: python setup.py py2exe
And this is my setup.py:
from distutils.core import setup
import py2exe
setup(console=['AutoArchive.py'])
Yes, that says 'console' for a Windows EXE, but swapping it to 'window' didn't help. Besides which, the setup.py file is straight from the old computer, so 'it used to work'.
What I have installed:
. python 2.7.13 (this in itself may be a problem - I don't even remember which version I was using earlier, other than knowing for sure it wasn't a 3.x release)
. wxpython (since I also got an error that wx module was missing - that rang some bells, since the script uses a Windows pop-up window to inform me about its progress, and I remember using wx for that, so I installed it, but don't know how to get its' version. using "python -c "import wx;print wx.__version__" just gives runtime errors).
Any help would be appreciated.
And yes, I googled, but can't really find anything (well, d'Uh!, I wouldn’t be here then would I?) - there's ~some~ references, but usually it's about similar issues on Linux, with solutions that are not applicable at all. Except one I thought: I found some link stating that _sysconfigdata is part of sysconfig, and that this needed to be installed with pip, so I used the pip that came with my python distro and did 'pip install [[_]sys]config[data]' (all possible combo's) but pip claims it can't find said module, and TBH, I can't seem to find anything myself about said module.
Thx,
Jimbo
Matthew Lemon
Jan 9, 2019, 12:06:35 AM1/9/19
to
Hi,
I would start from scratch with this.
1. You have latest Python 2 version.
2. Use virtualenv to create and activate a new virtual environment.
3. pip install wxPython and other dependencies.
4. Get your application running from the command line first and follow up any DLL exceptions.
5. Use pyinstaller (https://pyinstaller.readthedocs.io/en/stable/) to create a new exe file once you know everything works.
Matt
>--
>https://mail.python.org/mailman/listinfo/python-list
--
Sent from my Android device
I would start from scratch with this.
1. You have latest Python 2 version.
2. Use virtualenv to create and activate a new virtual environment.
3. pip install wxPython and other dependencies.
4. Get your application running from the command line first and follow up any DLL exceptions.
5. Use pyinstaller (https://pyinstaller.readthedocs.io/en/stable/) to create a new exe file once you know everything works.
Matt
>https://mail.python.org/mailman/listinfo/python-list
--
Sent from my Android device
dude....@gmail.com
Jan 9, 2019, 8:42:36 AM1/9/19
to
On Wednesday, January 9, 2019 at 6:06:35 AM UTC+1, Matthew Lemon wrote:
> Hi,
>
> I would start from scratch with this.
>
> 1. You have latest Python 2 version.
> 2. Use virtualenv to create and activate a new virtual environment.
> 3. pip install wxPython and other dependencies.
> 4. Get your application running from the command line first and follow up any DLL exceptions.
> 5. Use pyinstaller (https://pyinstaller.readthedocs.io/en/stable/) to create a new exe file once you know everything works.
>
> Matt
>
> Hi,
>
> I would start from scratch with this.
>
> 1. You have latest Python 2 version.
> 2. Use virtualenv to create and activate a new virtual environment.
> 3. pip install wxPython and other dependencies.
> 4. Get your application running from the command line first and follow up any DLL exceptions.
> 5. Use pyinstaller (https://pyinstaller.readthedocs.io/en/stable/) to create a new exe file once you know everything works.
>
> Matt
>
Step 2 you've lost me already. What is virtualenv, and why do I need it (this time round, not last time when I got it to work)? You don’t really need to respond, this is more of a rethorical question :).
Step 3 is I think the real issue. At first I was missing 'wx' and '_sysconfigdata', so I installed wxPhyton (via a windows installer that I found, not with pip), and that made the compile error go away (though it still throws runtime errors, of course). But what is '_sysconfigdata', and how do I install it? I - and pip :) - can't find a repo with that name!?
step 5, pyinstaller, is yet another hurdle I hope to avoid. It worked with py2exe, and it should still work with py2exe (within the efforts I'm prepared to put into this). Of course py2exe might be ancient and horrible and a bunch of other things that pyinstaller is not (I woulnd't know either way), but, to be honest, as well a tad cocky, I am not interested nor prepared to find out. Sorry about that, but hopefully one can understand. I'm not trying to 'get back into Python' , I just want something from the past back working again with minimal effort.
Trying to get it to work in console sounds like a (backup) plan though. I don't really need the 'progress' popup window, so I could keep the script in console only. That would potentially circumvent the issues, but I would have preferred if I simply got it back to work as is, like I managed to do - when I was still a bit more 'fluent' in Python - way back when on my previous machine…
Chris Angelico
Jan 9, 2019, 8:59:07 AM1/9/19
to
On Thu, Jan 10, 2019 at 12:46 AM <dude....@gmail.com> wrote:
> step 5, pyinstaller, is yet another hurdle I hope to avoid. It worked with py2exe, and it should still work with py2exe (within the efforts I'm prepared to put into this). Of course py2exe might be ancient and horrible and a bunch of other things that pyinstaller is not (I woulnd't know either way), but, to be honest, as well a tad cocky, I am not interested nor prepared to find out. Sorry about that, but hopefully one can understand. I'm not trying to 'get back into Python' , I just want something from the past back working again with minimal effort.
>
You want it to work with minimal effort? Then forget about py2exe and
> step 5, pyinstaller, is yet another hurdle I hope to avoid. It worked with py2exe, and it should still work with py2exe (within the efforts I'm prepared to put into this). Of course py2exe might be ancient and horrible and a bunch of other things that pyinstaller is not (I woulnd't know either way), but, to be honest, as well a tad cocky, I am not interested nor prepared to find out. Sorry about that, but hopefully one can understand. I'm not trying to 'get back into Python' , I just want something from the past back working again with minimal effort.
>
just distribute your .py files. WAY easier.
ChrisA
songbird
Jan 9, 2019, 9:57:13 AM1/9/19
to
Chris Angelico wrote:
...
person who might install it, if they are on a
different architecture or system it even gets
worse if you add in that they may need to figure
out how to get a C compiler installed and
available (if a bdist/wheel isn't available
because the developer couldn't figure out how
to generate one).
for a novice user who just wants to get
something done this isn't a very good solution.
a build farm for common architectures would
help a lot of developers avoid all this thrashing.
songbird
...
> You want it to work with minimal effort? Then forget about py2exe and
> just distribute your .py files. WAY easier.
which then forces the work onto every other
> just distribute your .py files. WAY easier.
person who might install it, if they are on a
different architecture or system it even gets
worse if you add in that they may need to figure
out how to get a C compiler installed and
available (if a bdist/wheel isn't available
because the developer couldn't figure out how
to generate one).
for a novice user who just wants to get
something done this isn't a very good solution.
a build farm for common architectures would
help a lot of developers avoid all this thrashing.
songbird
Grant Edwards
Jan 9, 2019, 9:58:58 AM1/9/19
to
On 2019-01-09, Chris Angelico <ros...@gmail.com> wrote:
> On Thu, Jan 10, 2019 at 12:46 AM <dude....@gmail.com> wrote:
> On Thu, Jan 10, 2019 at 12:46 AM <dude....@gmail.com> wrote:
>> step 5, pyinstaller, is yet another hurdle I hope to avoid. It worked with py2exe, and it should still work with py2exe (within the efforts I'm prepared to put into this). Of course py2exe might be ancient and horrible and a bunch of other things that pyinstaller is not (I woulnd't know either way), but, to be honest, as well a tad cocky, I am not interested nor prepared to find out. Sorry about that, but hopefully one can understand. I'm not trying to 'get back into Python' , I just want something from the past back working again with minimal effort.
>>
>
>>
>
> You want it to work with minimal effort? Then forget about py2exe and
> just distribute your .py files. WAY easier.
It may be easier, but it may not be feasible. That depends on what
> just distribute your .py files. WAY easier.
dependencies are involved and whether your target audience is capable
of installing Python and those dependencies. Distributing .py files
to my Windows customers is absolutely out of the question. There's no
way I can expect them to install Python and whatever other
dependenceis are required by my applications.
That said, I've recently switched from py2exe to cx_freeze. However,
even that isn't simple enough for my users, and I bundle the output
from those with Inno Setup.
--
Grant Edwards grant.b.edwards Yow! I'll show you MY
at telex number if you show me
gmail.com YOURS ...
MRAB
Jan 9, 2019, 10:27:46 AM1/9/19
to
MacOs, ...
How many platforms support .exe files that were compiled for Windows?
Grant Edwards
Jan 9, 2019, 10:36:03 AM1/9/19
to
On 2019-01-09, MRAB <pyt...@mrabarnett.plus.com> wrote:
> .py files work on any platform that supports Python: Windows, Linux,
> MacOs, ...
Only after python has been installed along with any other required
> .py files work on any platform that supports Python: Windows, Linux,
> MacOs, ...
libraries.
> How many platforms support .exe files that were compiled for Windows?
But when your requirement is to support Windows users who are not
capable of installing Python, WxWindows, and a half-dozen other
libraries, you can't simply hand out .py files, push your fingers into
your ears, close your eyes, and start yelling "your problem now, not
mine, na, na, na, na, na, ...."
--
Grant Edwards grant.b.edwards Yow! YOU PICKED KARL
at MALDEN'S NOSE!!
gmail.com
wxjm...@gmail.com
Jan 9, 2019, 12:12:01 PM1/9/19
to
on a Western European Win platform.
If fact, Python does not even work properly with the
*characters* of the Windows-1252 charset.
Rick Johnson
Jan 9, 2019, 12:42:13 PM1/9/19
to
Grant Edwards wrote:
What a tangled web we have woven...
>MRAB wrote:
>
> > .py files work on any platform that supports Python: Windows, Linux,
> > MacOs, ...
>
> Only after python has been installed along with any other required
> libraries.
And not just Python, but the correct _version_ of Python!
>
> > .py files work on any platform that supports Python: Windows, Linux,
> > MacOs, ...
>
> Only after python has been installed along with any other required
> libraries.
What a tangled web we have woven...
Chris Angelico
Jan 9, 2019, 12:58:17 PM1/9/19
to
On Thu, Jan 10, 2019 at 2:37 AM Grant Edwards <grant.b...@gmail.com> wrote:
blah Python sucks because py2exe is hard". That's not Python's fault.
You have an additional requirement ("support people who can't install
Python"), and that's going to have extra hassles. LOTS of them, in
this case.
ChrisA
>
> On 2019-01-09, MRAB <pyt...@mrabarnett.plus.com> wrote:
>
> > .py files work on any platform that supports Python: Windows, Linux,
> > MacOs, ...
>
> Only after python has been installed along with any other required
> libraries.
>
> On 2019-01-09, MRAB <pyt...@mrabarnett.plus.com> wrote:
>
> > .py files work on any platform that supports Python: Windows, Linux,
> > MacOs, ...
>
> Only after python has been installed along with any other required
> libraries.
>
> > How many platforms support .exe files that were compiled for Windows?
>
> None.
>
> But when your requirement is to support Windows users who are not
> capable of installing Python, WxWindows, and a half-dozen other
> libraries, you can't simply hand out .py files, push your fingers into
> your ears, close your eyes, and start yelling "your problem now, not
> mine, na, na, na, na, na, ...."
This is true - but on the flip side, it's a bit unfair to say "blah
>
> None.
>
> But when your requirement is to support Windows users who are not
> capable of installing Python, WxWindows, and a half-dozen other
> libraries, you can't simply hand out .py files, push your fingers into
> your ears, close your eyes, and start yelling "your problem now, not
> mine, na, na, na, na, na, ...."
blah Python sucks because py2exe is hard". That's not Python's fault.
You have an additional requirement ("support people who can't install
Python"), and that's going to have extra hassles. LOTS of them, in
this case.
ChrisA
Matthew Lemon
Jan 9, 2019, 1:07:43 PM1/9/19
to
If the OP was able to take the time to familiarise himself with the technologies, rather than bemoan the difficulty of deploying a ten year old code-base without mininal effort, he might have some success. Code rot is an issue after weeks sometimes, never mind ten years, and Python deployment is a weakness. However the tools do exist if you are prepared to give it a go. I've had most successful with pyinstaller, which is why I linked to it. Good luck!
Grant Edwards
Jan 9, 2019, 1:46:50 PM1/9/19
to
On 2019-01-09, Chris Angelico <ros...@gmail.com> wrote:
> On Thu, Jan 10, 2019 at 2:37 AM Grant Edwards <grant.b...@gmail.com> wrote:
>
>> > How many platforms support .exe files that were compiled for Windows?
>>
>> None.
>>
>> But when your requirement is to support Windows users who are not
>> capable of installing Python, WxWindows, and a half-dozen other
>> libraries, you can't simply hand out .py files, push your fingers into
>> your ears, close your eyes, and start yelling "your problem now, not
>> mine, na, na, na, na, na, ...."
>
> This is true - but on the flip side, it's a bit unfair to say "blah
> blah Python sucks because py2exe is hard". That's not Python's fault.
Of course not.
>
>> > How many platforms support .exe files that were compiled for Windows?
>>
>> None.
>>
>> But when your requirement is to support Windows users who are not
>> capable of installing Python, WxWindows, and a half-dozen other
>> libraries, you can't simply hand out .py files, push your fingers into
>> your ears, close your eyes, and start yelling "your problem now, not
>> mine, na, na, na, na, na, ...."
>
> This is true - but on the flip side, it's a bit unfair to say "blah
> blah Python sucks because py2exe is hard". That's not Python's fault.
> You have an additional requirement ("support people who can't install
> Python"), and that's going to have extra hassles. LOTS of them, in
> this case.
language on Microsoft Windows involves most of the same problems.
It's slightly easier for some languages than it is for others.
Just handing out .exe files built with nothing but the global default
C run-time library is possible -- but, when was the last time you saw
an application distributed like that?
--
Grant Edwards grant.b.edwards Yow! People humiliating
at a salami!
gmail.com
songbird
Jan 9, 2019, 4:05:09 PM1/9/19
to
Chris Angelico wrote:
...
as much as the C compiler that the graphics libs seem
to want to use during install from source. that is
likely not as easy to do. as i don't even have a
Windows machine here at all i can only read up on it
as much as i can and try to take some notes with me
of things to check and try out and hope that is
enough. i should be ok, but i'm not a Windows
expert by far. so ... :)
songbird
...
> This is true - but on the flip side, it's a bit unfair to say "blah
> blah Python sucks because py2exe is hard". That's not Python's fault.
> You have an additional requirement ("support people who can't install
> Python"), and that's going to have extra hassles. LOTS of them, in
> this case.
i'm not as much worried about the python 3 install
> blah Python sucks because py2exe is hard". That's not Python's fault.
> You have an additional requirement ("support people who can't install
> Python"), and that's going to have extra hassles. LOTS of them, in
> this case.
as much as the C compiler that the graphics libs seem
to want to use during install from source. that is
likely not as easy to do. as i don't even have a
Windows machine here at all i can only read up on it
as much as i can and try to take some notes with me
of things to check and try out and hope that is
enough. i should be ok, but i'm not a Windows
expert by far. so ... :)
songbird
songbird
Jan 9, 2019, 4:05:11 PM1/9/19
to
Matthew Lemon wrote:
> If the OP was able to take the time to familiarise himself with the technologies, rather than bemoan the difficulty of deploying a ten year old code-base without mininal effort, he might have some success. Code rot is an issue after weeks sometimes, never mind ten years, and Python deployment is a weakness. However the tools do exist if you are prepared to give it a go. I've had most successful with pyinstaller, which is why I linked to it. Good luck!
i looked at it, will require further reading/testing.
> If the OP was able to take the time to familiarise himself with the technologies, rather than bemoan the difficulty of deploying a ten year old code-base without mininal effort, he might have some success. Code rot is an issue after weeks sometimes, never mind ten years, and Python deployment is a weakness. However the tools do exist if you are prepared to give it a go. I've had most successful with pyinstaller, which is why I linked to it. Good luck!
i see part of my list of modules are supported but
not sure all are without a test. will have to look into
it further. tks. :)
songbird (not the OP, but in a similar and perhaps
more complicated boat...
songbird
Jan 9, 2019, 4:05:11 PM1/9/19
to
using compile C code during the install. i'd be
happier if they didn't, but i don't have a way to
easily generate those files myself that i know of.
> How many platforms support .exe files that were compiled for Windows?
i have some pretty ancient Windows/DOS programs
that work fine under dosbox in my Debian Linux testing
setup. i haven't checked them out lately though to
see if they're still runnable (good chance they're
ok). been busy with other things and besides i
finally moved the ancient spreadsheets from Multiplan
to Libreoffice.
songbird
songbird
Jan 9, 2019, 4:05:12 PM1/9/19
to
Grant Edwards wrote:
...
alas, i have no Windows or MacOS machines to
generate any binaries, though i would guess that
the MacOS may have an easier path to getting
a C compiler installed (but i don't know, my MacOS
person hasn't said anything yet).
in looking at the Python install for Windows it
looks like i will probably want to do it to make
sure that the paths are set up correctly. the C
compiler, don't know how easy that might be until
i do it, which i hate when sitting in someone
else's house with them hovering. considering i
haven't touched Windows since XP and really am
not an expert these days it should be entertaining.
my code is all python 3 so that at least should
simplify some things.
songbird
...
> That said, I've recently switched from py2exe to cx_freeze. However,
> even that isn't simple enough for my users, and I bundle the output
> from those with Inno Setup.
i looked at the one and stopped at that because
> even that isn't simple enough for my users, and I bundle the output
> from those with Inno Setup.
alas, i have no Windows or MacOS machines to
generate any binaries, though i would guess that
the MacOS may have an easier path to getting
a C compiler installed (but i don't know, my MacOS
person hasn't said anything yet).
in looking at the Python install for Windows it
looks like i will probably want to do it to make
sure that the paths are set up correctly. the C
compiler, don't know how easy that might be until
i do it, which i hate when sitting in someone
else's house with them hovering. considering i
haven't touched Windows since XP and really am
not an expert these days it should be entertaining.
my code is all python 3 so that at least should
simplify some things.
songbird
dude....@gmail.com
Jan 10, 2019, 10:05:44 AM1/10/19
to
Well that escalated quickly :).
So, no-one can tell me which component to pip to get rid of "missing ['_sysconfigdata']" error?
So, no-one can tell me which component to pip to get rid of "missing ['_sysconfigdata']" error?
dude....@gmail.com
Jan 11, 2019, 9:36:05 AM1/11/19
to
Really, no-one?
OK, more purging then. I ~think~ I need said missing component because the script gets the system date (to run once on a Friday, in automatic mode). But I've never used it in automatic mode (since I came to my senses about having an infinite looping script in my autoexec.bat, doing nothing, except executing once on a friday, and wasting resources).
So, if I scrap the automatic mode, I guess I might finally have something that 'works'.
Still disappointed though that I can't get it to work again with the same 'tools' as previously. Especially since I also use the date to add to the name of the backup files that the script is making.
Oh, as for 'distributing' this thing. It's a private/personal script, so I'm my only customer. In this sense, I don't even need the EXE now that I've scrapped automatic mode. I can just run the *.py straight from a console. Oh well.
Would anyone be interested in seeing the - now infamous - script, to have a go yourself?
OK, more purging then. I ~think~ I need said missing component because the script gets the system date (to run once on a Friday, in automatic mode). But I've never used it in automatic mode (since I came to my senses about having an infinite looping script in my autoexec.bat, doing nothing, except executing once on a friday, and wasting resources).
So, if I scrap the automatic mode, I guess I might finally have something that 'works'.
Still disappointed though that I can't get it to work again with the same 'tools' as previously. Especially since I also use the date to add to the name of the backup files that the script is making.
Oh, as for 'distributing' this thing. It's a private/personal script, so I'm my only customer. In this sense, I don't even need the EXE now that I've scrapped automatic mode. I can just run the *.py straight from a console. Oh well.
Would anyone be interested in seeing the - now infamous - script, to have a go yourself?
dude....@gmail.com
Jan 11, 2019, 9:46:09 AM1/11/19
to
Oh, another thing. I installed WX via a windows installer that I found (can't find the link again, but fairly certain it was this one: https://sourceforge.net/projects/wxpython/ (*)), without giving it much thought (yesyes bad mistake).
Since I get wx runtime errors, I'm assuming I have the wrong version. So, in all my 45-yo youthful ignorance, I ran 'pip install -U wxPython' hoping it would magically erase the previously installed version - whatever that is - and get me the newest one. What actually happens is the cmd-window freezing, and nothing else…
(*) The 'proper' method to install it, I obviously found on "https://wiki.wxpython.org/How%20to%20install%20wxPython#Windows", but that led me to 'pip', which at that moment in time - 2 days ago LOL - I was not ready for yet (Hey, I'm doing this in between actual work, putting kids in bed, and passing out on the sofa)
Since I get wx runtime errors, I'm assuming I have the wrong version. So, in all my 45-yo youthful ignorance, I ran 'pip install -U wxPython' hoping it would magically erase the previously installed version - whatever that is - and get me the newest one. What actually happens is the cmd-window freezing, and nothing else…
(*) The 'proper' method to install it, I obviously found on "https://wiki.wxpython.org/How%20to%20install%20wxPython#Windows", but that led me to 'pip', which at that moment in time - 2 days ago LOL - I was not ready for yet (Hey, I'm doing this in between actual work, putting kids in bed, and passing out on the sofa)
Message has been deleted
dude....@gmail.com
Jan 11, 2019, 11:13:40 AM1/11/19
to
OK, stop the presses. Or, rather, refresh your browser, I guess.
In a 'what the !@$$ am I doing'-moment (I don't get those often) I uninstalled everything and went gardening. But it was raining so I installed everything again, this time using pip for wxpython. Lo and behond, this time it did not crash the cmd-window, but in stead it successfully installed it.
Woot.
Then I compiled again with same command and same setup.py and - stubbornly - with py2exe, and got… different errors! That's actually a good sign. No, really.
Because this time, the error was about missing Windows DLLs and here I got plenty of help from my best friend Google (don't tell JackD he's actually second best friend). So, after x iterations I ended up with the following cute setup.py:
<-
options={
'py2exe': {
'dll_excludes': ['api-ms-win-core-string-l1-1-0.dll', 'api-ms-win-core-psapi-l1-1-0.dll', 'api-ms-win-core-registry-l1-1-0.dll',
'api-ms-win-core-localization-l1-2-0.dll', 'api-ms-win-security-base-l1-1-0.dll', 'api-ms-win-core-string-obsolete-l1-1-0.dll',
'api-ms-win-core-delayload-l1-1-0.dll', 'api-ms-win-core-handle-l1-1-0.dll', 'api-ms-win-crt-private-l1-1-0.dll',
'api-ms-win-core-libraryloader-l1-2-1.dll', 'api-ms-win-core-memory-l1-1-0.dll', 'api-ms-win-core-heap-obsolete-l1-1-0.dll',
'api-ms-win-core-atoms-l1-1-0.dll', 'api-ms-win-core-processthreads-l1-1-1.dll', 'api-ms-win-core-heap-l2-1-0.dll',
'api-ms-win-core-delayload-l1-1-1.dll', 'api-ms-win-core-processthreads-l1-1-0.dll', 'api-ms-win-core-com-midlproxystub-l1-1-0.dll',
'api-ms-win-crt-string-l1-1-0.dll', 'api-ms-win-crt-runtime-l1-1-0.dll', 'api-ms-win-core-libraryloader-l1-2-0.dll',
'api-ms-win-core-errorhandling-l1-1-0.dll', 'api-ms-win-core-string-l2-1-0.dll', 'api-ms-win-core-synch-l1-2-0.dll',
'api-ms-win-core-profile-l1-1-0.dll', 'api-ms-win-core-synch-l1-1-0.dll', 'api-ms-win-core-threadpool-legacy-l1-1-0.dll',
'api-ms-win-core-interlocked-l1-1-0.dll', 'api-ms-win-core-debug-l1-1-0.dll', 'api-ms-win-core-sysinfo-l1-1-0.dll']
}
},
)
->
After which all the missing DLL errors were finally gone (and no, I don’t wanna know why all of the above is even necessary). Success!! Or not? Because I was now right back at:
<-
->
You cannot possibly be serious!? _sysconfigdata is back… with a friend!
Luckily it was still raining so my plan to blow up the PC in my garden fire pit (and dancing hysterically around the glorious resulting bonfire, while in the nude) got scrapped, which allowed me to notice that an actual dist folder had in fact been created, and not just that, there was an EXE inside!
So I ran it.
and it worked.
It worked!
It did exactly what it needed to do. Just like on my old machine. I even got the fancy progress popup and the date string in my file names.
(At this point I ~did~ dance in the nude, albeit in front of the PC)
So what lessons did I learn:
1) compile errors apparently mean Sweet-BLEEP-All;
2) close the curtains when dancing naked around the PC;
3) the back of modern day PCs, which typically sit at groin height on your desk, get really hot at the back. Avoid contact with exposed body parts;
4) there's clearly a reason why I 'gave up on Python' those 10 years ago, and perhaps I'm slowly starting to remember why… :|
Jimbo.
In a 'what the !@$$ am I doing'-moment (I don't get those often) I uninstalled everything and went gardening. But it was raining so I installed everything again, this time using pip for wxpython. Lo and behond, this time it did not crash the cmd-window, but in stead it successfully installed it.
Woot.
Then I compiled again with same command and same setup.py and - stubbornly - with py2exe, and got… different errors! That's actually a good sign. No, really.
Because this time, the error was about missing Windows DLLs and here I got plenty of help from my best friend Google (don't tell JackD he's actually second best friend). So, after x iterations I ended up with the following cute setup.py:
<-
from distutils.core import setup
import py2exe
setup(console=['AutoArchive.py'],
import py2exe
options={
'py2exe': {
'dll_excludes': ['api-ms-win-core-string-l1-1-0.dll', 'api-ms-win-core-psapi-l1-1-0.dll', 'api-ms-win-core-registry-l1-1-0.dll',
'api-ms-win-core-localization-l1-2-0.dll', 'api-ms-win-security-base-l1-1-0.dll', 'api-ms-win-core-string-obsolete-l1-1-0.dll',
'api-ms-win-core-delayload-l1-1-0.dll', 'api-ms-win-core-handle-l1-1-0.dll', 'api-ms-win-crt-private-l1-1-0.dll',
'api-ms-win-core-libraryloader-l1-2-1.dll', 'api-ms-win-core-memory-l1-1-0.dll', 'api-ms-win-core-heap-obsolete-l1-1-0.dll',
'api-ms-win-core-atoms-l1-1-0.dll', 'api-ms-win-core-processthreads-l1-1-1.dll', 'api-ms-win-core-heap-l2-1-0.dll',
'api-ms-win-core-delayload-l1-1-1.dll', 'api-ms-win-core-processthreads-l1-1-0.dll', 'api-ms-win-core-com-midlproxystub-l1-1-0.dll',
'api-ms-win-crt-string-l1-1-0.dll', 'api-ms-win-crt-runtime-l1-1-0.dll', 'api-ms-win-core-libraryloader-l1-2-0.dll',
'api-ms-win-core-errorhandling-l1-1-0.dll', 'api-ms-win-core-string-l2-1-0.dll', 'api-ms-win-core-synch-l1-2-0.dll',
'api-ms-win-core-profile-l1-1-0.dll', 'api-ms-win-core-synch-l1-1-0.dll', 'api-ms-win-core-threadpool-legacy-l1-1-0.dll',
'api-ms-win-core-interlocked-l1-1-0.dll', 'api-ms-win-core-debug-l1-1-0.dll', 'api-ms-win-core-sysinfo-l1-1-0.dll']
}
},
)
->
After which all the missing DLL errors were finally gone (and no, I don’t wanna know why all of the above is even necessary). Success!! Or not? Because I was now right back at:
<-
The following modules appear to be missing
['Carbon.Appearance', '_sysconfigdata']
->
You cannot possibly be serious!? _sysconfigdata is back… with a friend!
Luckily it was still raining so my plan to blow up the PC in my garden fire pit (and dancing hysterically around the glorious resulting bonfire, while in the nude) got scrapped, which allowed me to notice that an actual dist folder had in fact been created, and not just that, there was an EXE inside!
So I ran it.
and it worked.
It worked!
It did exactly what it needed to do. Just like on my old machine. I even got the fancy progress popup and the date string in my file names.
(At this point I ~did~ dance in the nude, albeit in front of the PC)
So what lessons did I learn:
1) compile errors apparently mean Sweet-BLEEP-All;
2) close the curtains when dancing naked around the PC;
3) the back of modern day PCs, which typically sit at groin height on your desk, get really hot at the back. Avoid contact with exposed body parts;
4) there's clearly a reason why I 'gave up on Python' those 10 years ago, and perhaps I'm slowly starting to remember why… :|
Jimbo.
0 new messages