On Wed, 18 Sep 2013 17:39:05 -0700 (PDT) Jacob Barhak wrote: JB Does anyone have an easy way to install WxPython that is more or less the JB same on all platforms? The only really painless way to do it is by using the distribution-provided binaries. We have good hopes that wxWidgets 3.0 will be included in Debian (and then Ubuntu) relatively soon after its release.
But it still must be released first:-( JB The 2.9 instructions are simpler yet when I run the build script it fails JB to find opengl. You need to install the dependencies, i.e. Libgl1-mesa-dev and libglu1-mesa-dev packages or similar.
Regards, VZ - TT-Solutions: wxWidgets consultancy and technical support Jacob Barhak 4/7/2014, 14:46 น. On Fri, 4 Jul 2014 14:46:31 -0700 (PDT) Jacob Barhak wrote: JB Ubuntu 14.04 LTS is out. The synaptic package manager does not JB show wxpython 3.0 - it has 2.8. Did I not see it, or perhaps it is not JB there yet?
I do see wxGTK 3.0 in it but wxPython seems to be stuck at 2.8 (even in Utopic). This is unfortunate, but there is really not much we can do about it. JB However, I am still stuck with the inability to install wxpython seamlessly JB for a user different than me on Ubuntu. It seems just too complex - even JB for a developer. AFAIK it's just a matter of running 'setup.py install' (see for more details). Of course, it's possible that something is broken and you ran into some problem while doing it, but we'd really need to know what it was in order to be able to help you.
Installing Python 3 on Mac OS X¶. The latest version of Mac OS X, High Sierra, comes with Python 2.7 out of the box. You do not need to install or configure anything.
JB The installation problem has been open for years and now there are tools JB that can help close this for good. Most people strongly prefer to use distribution package manager for installing everything, so I'm really not sure if this N+1-st solution is going to be as final as you think.
In any case, we can only try to make building things from source as simple as possible and IMHO they are quite straightforward for wxPython already (and definitely are for wxGTK itself). If you have any problems with building from source, please post here. Unfortunately I can't promise to help with anything else. Jacob Barhak 5/7/2014, 13:32 น. Thanks Vadim, Your willingness to help is nice. However, the issue is much bigger.
I am stuck with the Linux issue for many months now. For example, the link you sent me contains out of date documentation. If you go through the build instructions it links to you will find out that they don't match the last version.
When I needed to build Wxpython 3.0 a few month ago I needed to use a patch that was not documented anywhere but this mailing list. I was eventually successful to some degree yet if I want my application to depend on WxPython I cannot leave this complexity to the user. Just to explain, my potential user may not know what python is. And some have trouble locating the command prompt.
Running python setup.py in the correct directory may be too demanding to ask from such a user. Therefore if my application uses WxPython I must have a simple way to install it for the user with my application. The fact that you are willing to help me solve problems is comforting, yet it helps only me, not my potential users. Think about it, for each developer there are multiple users. If the developer cannot package the solution for the users then you will have to serve them all.
However, if you can package the solution in a way that can be forwarded to others, you have a good solution - which will attract users. The conda solution works on Windows. I can install my app through a conda command in a system without WxPython and my app works great after conda detects WxPython as a dependency and installs the necessary binaries. The user does not know what happened and does not need to seek help through this list. However, I cannot get the same thing to work on Ununtu. Either the system breaks on GLibC or a different WxPython version seems to behave funny - depending on binaries used - see my last post. My question is, how hard it is to create a set of binaries that will work on a barebones Ubuntu installation and package these as an official WxPython install through conda?
Do you need a different set of binaries for each Linux distribution? Even if so, the process of creating those can be automated. The guys from Continuum Analytics have done a big stride forward with conda in this regard. Windows is well covered and Linux is half working. Can a WxPython expert help finish the job and make it work fully? Creating a conda package is relatively easy, can this be the method to install all binaries?
This is what I am aiming at. I hope someone can help here. Jacob Sent from my iPhone Igor Korot 5/7/2014, 14:02 น. On Sat, Jul 5, 2014 at 1:32 PM, Jacob Barhak wrote: Thanks VadimYour willingness to help is nice.
However, the issue is much bigger. I am stuck with the Linux issue for many months now. Why you users needs to install wxPython? All you need to do is to install it on you machine.
Then you will develop you software and when its ready you will make a binary executable from it and distribute this binary among the users. Search the web. There are many solutions to make the binary from python/wxPython. - Please read before posting. To unsubscribe, send email to or visit Jacob Barhak 5/7/2014, 14:36 น.
Sorry Igor, You will have to be clearer and point out a solution that will specifically fit me. And distributing binaries is not a satisfactory solution here. My software is pure python and it uses WxPython for GUI.
Once I write import wx in my code then I cannot give my software to someone else without asking them to install WxPython first. Python works more or less the same on all platforms, so distributing it should be easy. However, once I include WxPython as a dependency I get into all sorts of binary problems that are foreign to python. Note that most packages in python have installers through pip install easyinstall or conda that work cross platform.
For some reason WxPython lacks this. Conda is a new tool that resolves many issues with versions and installation and can deal with binaries as well as python and in combination with binstar can give a solution for the community and for WxPython to distribute binaries in a way that will make installation of dependencies easier.
For example my system uses the Inspyred library. I was able to create an Inspyred package in my binstar account. When I install my software using conda the system knows to install Inspyred for me without me asking. Doing the same for WxPython is much harder. It is far from writing python setup.py.
There are many hidden dependencies there. Something in WxPython makes it much harder and therefore an expert should do this. Fortunately using binstar and conda is not difficult, so an expert can easily do that. And someone actually did that, yet it needs some fine tuning. Is there an expert who can resolve this on this list? I hope there is. Jacob Sent from my iPhone Igor Korot 5/7/2014, 14:56 น.
Jacob, On Sat, Jul 5, 2014 at 2:36 PM, Jacob Barhak wrote: Sorry IgorYou will have to be clearer and point out a solution that will specifically fit me. And distributing binaries is not a satisfactory solution here. Check out py2exe and pyinstaller. I don't have a reference for the former but pyinstaller can be found at. Now my employer says that they had issues with py2exe and they use pyinstaller, but I don't know about that. You can try both and see if any will satisfy you needs.
Jacob Barhak 5/7/2014, 15:22 น. Thanks Igor, Yet py2exe is not a good solution and I doubt PyInstaller will help since my code calls python to invoke scripts. I actually played around with py2exe a few years ago without much success.
However, it will not install on Linux if the name is descriptive. My windows problem is actually already fully solved with conda that is able to install WxPython correctly as a dependency. My issues are with the WxPython Linux installation that seems to be not fully solved.
This is where I am asking for help. If someone knows how to properly build and package WxPython on Ubuntu using conda and binstar then I have a perfect solution for both Linux and windows.
Yet thank you for suggesting these paths. Jacob Sent from my iPhone Igor Korot 5/7/2014, 15:36 น. Jacob, On Sat, Jul 5, 2014 at 3:20 PM, Jacob Barhak wrote: Thanks IgorYet py2exe is not a good solution and I doubt PyInstaller will help since my code calls python to invoke scripts. I actually played around with py2exe a few years ago without much success. However, it will not install on Linux if the name is descriptive. My windows problem is actually already fully solved with conda that is able to install WxPython correctly as a dependency. You didn't look at pyinstaller.
Let me quote the homepage: ' PyInstaller is a program that converts (packages) Python programs into stand-alone executables, under Windows, Linux, Mac OS X, Solaris and AIX. Its main advantages over similar tools are that PyInstaller works with any version of Python since 2.4, it builds smaller executables thanks to transparent compression, it is fully multi-platform, and use the OS support to load the dynamic libraries, thus ensuring full compatibility. The main goal of PyInstaller is to be compatible with 3rd-party packages out-of-the-box. This means that, with PyInstaller, all the required tricks to make external packages work are already integrated within PyInstaller itself so that there is no user intervention required. You'll never be required to look for tricks in wikis and apply custom modification to your files or your setup scripts. As an example, libraries like PyQt, Django or matplotlib are fully supported, without having to handle plugins or external data files manually.
Check our compatibility list of SupportedPackages for details. ' First paragraph says that pyinstaller will package any python (not just wxPython) script under all OS. Now once again. It will not help you install wxPython.
It will help you make binary executable out of you python script that is ready to be distributed. Vadim Zeitlin 5/7/2014, 16:38 น. On Sat, 5 Jul 2014 15:32:50 -0500 Jacob Barhak wrote: JB For example, the link you sent me contains out of date documentation. I looked it over before posting it and didn't see anything obviously wrong with it. What is the problem exactly?
And, if you already have the solution, perhaps you could fix it directly on the wiki? JB If you go through the build instructions it links to you will find out JB that they don't match the last version. When I needed to build Wxpython JB 3.0 a few month ago I needed to use a patch that was not documented JB anywhere but this mailing list. I was eventually successful to some JB degree yet if I want my application to depend on WxPython I cannot JB leave this complexity to the user. It's difficult to tell anything about this without knowing what the problem was and what the patch is.
JB Just to explain, my potential user may not know what python is. And JB some have trouble locating the command prompt. IMO the solution to this problem is to build a normal Debian package which can be installed using the normal system tools (including GUI ones). JB The conda solution works on Windows. I don't know anything about conda, all I know is that there are dozens of similar systems.
Some of them are more widespread than others (0install comes to mind), but I don't think any of them are ready to replace the packages in the system format (RPM or DEB) any time soon. So while I wish you good luck with solving your problem, I think this approach is misguided. Jacob Barhak 5/7/2014, 18:34 น. Thanks Igor, Your enthusiasm is in place yet does not provide a solution. I was referring to py2exe with window only in mind. I did look at PyInstaller yet did not try it since a system that compile my python into executables breaks it. In some case my system calls python to invoke scripts it writes on the fly.
And unless PyInstaller replicates what conda does and installs the python environment for you then it will break. If you have experience with PyInstaller that contradicts this, please let me know. My choice with conda is justified here since it just transfers the eco system of the application and does not try to change the code into an executable.
I believe someone on the list is capable of building a working Ubuntu WxPython package. If this is done I will be able to help upload it to binstar for conda install.
Jacob Sent from my iPhone Jacob Barhak 5/7/2014, 18:42 น. Jacob, On Sat, Jul 5, 2014 at 6:34 PM, Jacob Barhak wrote: Thanks IgorYour enthusiasm is in place yet does not provide a solution. Let me assure you that I'm not in any way affiliated to the Pyinstaller or its developers.;-) I was referring to py2exe with window only in mind. I did look at PyInstaller yet did not try it since a system that compile my python into executables breaks it. You mean you can't install PyInstaller itself? Did you try the package manager or compiling from source?
I'm sure PyInstaller devs will be happy to provide support for it. In some case my system calls python to invoke scripts it writes on the fly. And unless PyInstaller replicates what conda does and installs the python environment for you then it will break. You mean that you code is written like this: def foo wx.Execute('python myscript.py')? Can't you just import the script you are trying to run and call the appropriate function? And also conda installs the whole python environment on the system? This is just a big waste of the resources as the idea behind binary is to run the program without the need to depend on the developmental environment.
Also, out of curiosity, what Linux comes without Python pre-installed? If you have experience with PyInstaller that contradicts this, please let me know.
My choice with conda is justified here since it just transfers the eco system of the application and does not try to change the code into an executable. I'm just a developer that work on the (wx)Python scripts. But IIUC, my solutions probably is not a good fit/match, unless you try it yourself and tell me that its not good.;-) Thank you. Jacob Barhak 5/7/2014, 22:52 น. As promised, attached are results of running winpdb after installing WxPython through conda install.
The first file shows the default installation that plain does not work and breaks on LibC. The second file shows the alternative installation by Aaron Meurer that does work, yet has some incompatibilities. Aaron once told me he compiled against older libraries, yet since I do not know details you will need to ask him. And he also maintains conda, so you will be able to get information on conda at the same time. Now I have given you lots of information here. Please understand. What I want are a set of instructions that will allow me to build a conda package on a fresh installation of Ubuntu 14.04LTS.
Once this is done properly I can try to write a conda build script for those and upload the package to binstar so others can install it. The conda part should be easy if WxPython is properly prepared - as far as I understand. And since this works smoothly on windows and partially works on Linux already I think my solution is guided well.
It is a MIcro Simulation Compiler and run environment. About 8 years ago when working on MIST predecessor IEST we chose python and WxPython as development platforms. It was a good choice at the time.
Yet installation was always an issue and many people who work in the disease modeling field rarely understand the details we are discussing now. They want a solution that just works. I am trying to get to this point. I am happy to tell you that with windows I am successful. I was able to do this through conda. Yet Linux need some more work - this is why I am on this list asking for insights. And yes, I do call python from my code as a process in multiple scripts, even in my test code.
However, I did not do this in WxPython like in your example - there it is handled differently. Any system that turns my code into an executable will not be able to capture those calls to python through a process. And even if it is smart enough to redirect these to the python that comes standard with Ubuntu then it will break for not having the dependencies I need such as numpy, Inspyred etc. Unless of course it does what conda does and installs those packages. On 06/07/14 02:34, Jacob Barhak wrote: Thanks Igor, Your enthusiasm is in place yet does not provide a solution. I was referring to py2exe with window only in mind. I did look at PyInstaller yet did not try it since a system that compile my python into executables breaks it. In some case my system calls python to invoke scripts it writes on the fly.
And unless PyInstaller replicates what conda does and installs the python environment for you then it will break. If you have experience with PyInstaller that contradicts this, please let me know.
My choice with conda is justified here since it just transfers the eco system of the application and does not try to change the code into an executable. I believe someone on the list is capable of building a working Ubuntu WxPython package.
If this is done I will be able to help upload it to binstar for conda install. Jacob Sent from my iPhone On Jul 5, 2014, at 5:36 PM, Igor Korot wrote: Jacob, Just to clarify, what I think Igor is getting at but is being missed - pyInstaller may be an ideal solution for you, if as you say you need to write python scripts dynamically from within your code and invoke those python scripts and then invoke them from within your program. This is because what it does is to compress python, your code and the dependent libraries (including 3rd party libraries) into a single binary executable for the targeted platform, including Linux. As such all python built in commands are always available including compile and exec which will allow you to write your executable script to a file or string, compile it and then call it just as if you were to write it to a.py file and then invoke that file. The good news is that if you opt for the generate as a string and then compile from it you will:. Not be littering your users disk space with generated file,. Not be vulnerable to malicious persons tampering with the content of such files, (one classic approach is to add code to such files),.
In some cases this may avoid false alarms of possible malicious code,. Run faster on most systems as you are working entirely in RAM.
Your program will not be forcing the installation of a system level python, libraries, etc., which may be an issue for some users as doing so as it:. may cause conflicts with code that they are also using, e.g. Jacob/Steve, On Sun, Jul 6, 2014 at 12:34 AM, Steve Barnes wrote: On 06/07/14 02:34, Jacob Barhak wrote: Thanks IgorYour enthusiasm is in place yet does not provide a solution. I was referring to py2exe with window only in mind. I did look at PyInstaller yet did not try it since a system that compile my python into executables breaks it. In some case my system calls python to invoke scripts it writes on the fly.
And unless PyInstaller replicates what conda does and installs the python environment for you then it will break. If you have experience with PyInstaller that contradicts this, please let me know.
My choice with conda is justified here since it just transfers the eco system of the application and does not try to change the code into an executable. I believe someone on the list is capable of building a working Ubuntu WxPython package. If this is done I will be able to help upload it to binstar for conda install. Jacob Sent from my iPhone There is one more point - besides Ubuntu way, there is Solaris way, where you have Solaris package manager, there is a Debian way - where there is Debian installer, there is Gentoo way where there is Gentoo installer and so on. So you can't expect that one way will satisfy every possible Linux distribution in the world. Moreover, I think that the approach where python is spawned as a process might be wrong.
What he can do is import the python module and execute the function that runs this script. But that's not for me to suggest since this approach works.
Gadget/Steve Jacob Barhak 6/7/2014, 2:46 น. Hi, Jacob, On Sun, Jul 6, 2014 at 2:46 AM, Jacob Barhak wrote: Thanks Steve, Thanks IgorYour points are taken.
Yet please agree with me that my bottleneck is build WxPython on Linux to work properly. I would love to, but can't. Like I and Steve said - all you need to do is to get PyInstaller to package the program for you on the host system and then ship that packaged binaries to you user. No pain of installing 3rd party libraries, no wxPython installation, no python installation.
Zero work for user. Download and run. It will not require tweaking of anything (AFAIU, you had to fix something for conda). Install PyInstaller. Package you script. 3 Distribute binaries.
Move to another OS. If no more OS - finish. Steve, Thank you for the explanation. Something to be put in my notepad for the future references. If this is solved I can later install with multiple systems. I can have a conda install and another type of install.
The main thing is: even if you make the installer for Ubuntu, it will not be accepted in the Ubuntu and you will have to distribute this installer either independently or inside you conda package. The reason being that there are packages that depends on wxPython and so maintainer of wxPython in Ubuntu will have to go thru the chain, making sure that everything builds and works works properly with different python versions and only then pushing the package in the repository. This is a long process as the wxPython maintainer is usually maintains many packages. Using PyInstaller is much simpler and much faster. It will save a lot of time and money. Jacob Barhak 6/7/2014, 3:36 น. Thanks Igor, Yet you still need to get WxPython install on the development machine.
Currently I cannot do this with Ubuntu. If you are suggesting that PyInstaller will install libraries on another system in all cases I plainly do not believe it. Some dependencies are platform dependent. And if your claims are correct, please create a PyInstaller for WxPython. If it works as you claim I will install on Ubuntu and then create my conda package using those binaries. Unless you are capable of doing so as easily as you described, please let those who can resolve the WxPython build issue on Ubuntu help out. Jacob Sent from my iPhone Igor Korot 6/7/2014, 3:57 น.
Jacob, On Jul 6, 2014 3:36 AM, 'Jacob Barhak' wrote: Thanks IgorYet you still need to get WxPython install on the development machine. Currently I cannot do this with Ubuntu. Yes, but how can you develop without wxPython? Or you are using pre-built binary? If you are suggesting that PyInstaller will install libraries on another system in all cases I plainly do not believe it. Some dependencies are platform dependent. You are missing the point here.
PyInstaller will make the binary executable (exe file on Windows) which you end user will be able to run. And if you build it on Windows it will collect Windows dependency. If not you should be able to help.
And if your claims are correct, please create a PyInstaller for WxPython. If it works as you claim I will install on Ubuntu and then create my conda package using those binaries. The problem here is that I don't have wxPython and you software on my Gentoo box to make such a binary. So unless I have scripts you wrote I will not be able to do so.
Unless you are capable of doing so as easily as you described, please let those who can resolve the WxPython build issue on Ubuntu help out. Now let me ask you this - are you trying to build from sources? Vadim Zeitlin 6/7/2014, 11:29 น. On Sun, 6 Jul 2014 00:52:16 -0500 Jacob Barhak wrote: JB As promised, attached are results of running winpdb after installing JB WxPython through conda install. The first file shows the default JB installation that plain does not work and breaks on LibC. This has nothing to do with wxPython nor wxWidgets, it's just a wrong version of glibc for the system the package is being installed on. I can't help with this at all and, again, this is just not something that can happen when using the OS package manager as it takes care of conflicts like this via dependencies and the sole fact that the package system you use allows you to install an incompatible package is a pretty serious indication that it's completely broken.
JB The second file shows the alternative installation by Aaron Meurer that JB does work, yet has some incompatibilities. I don't know what are these incompatibilities. If they prevent the program from running, please post more information about them here or ask the people who're interested in fixing this to do it. The GTK+ debugging messages shown in your attachment are not necessarily fatal and could be actually result of a (relatively harmless) bug in wxWidgets itself which doesn't prevent anything from working. JB As for the build instructions being out out date, here is a link to the JB recipe I used to compile WxPython half a year ago: JB JB JB This is a bit different than the instructions here: JB JB JB The missing parts are the patch and the dependency installations before JB starting the build.
I had to collect those from multiple posts. The patch against 2.9.5 is hopefully not needed any longer with 3.0.1. Dependencies do need to be installed, please add them to wxPython wiki if they're missing from there.
JB Yet after building successfully something was still missing - the system JB worked with the python supplied with Linux, yet not with anaconda - GlibC JB again was the issue - as I mentioned it is a recurring nightmare. I think you need to stop for a moment and actually think of what are you doing. You should realize that you simply can't install anything linked against an incompatible version of glibc on a system which doesn't have it. I don't understand why are you calling it a nightmare, it's really something quite obvious: if you build something on a new system using dynamic linking, you can't use it on an older system. The typical solution is to build on an old system, using minimal versions of glibc and GTK+ you want to support. The produced binaries will work on any system with the same or newer versions of glibc and GTK+.
Again, it is really simple, but you do need to understand what are you doing. JB Yet since then Aaron supplied a working WxPython installation with conda. I JB just want it to work as in windows, Currently it raises the warnings as you JB see in the alternative file and does not behave like the windows version JB when running my system. GetRange also seems to be the warning that repeats JB itself and for some reason the alternative WxPython version cannot read JB text from a text box in once case that works well on windows. JB JB Now I have given you lots of information here. Sorry, but no, you didn't.
The above paragraph is as vague as it can possibly be. I have no idea what is the problem with GetRange. I don't understand what do you mean by 'cannot read text from a text box'. Does it return an empty string? Does it happen regardless of the text control contents or only for some specific strings? Does it happen for all text controls or only for some particular one and, if so, what is special about it?
You need to spend more time on trying to isolate the problem before we can do anything about it. JB Please understand. What I want are a set of instructions that will JB allow me to build a conda package Unfortunately I can't help you with this. I really have zero interest in spending time on yet another non standard packaging system, especially one which seems to be broken (see the beginning of this email). My advice remains the same: build wxPython.deb and maybe your own.deb with wxPython as a dependency and just tell your users to install it (you can easily create your own PPA if you target Ubuntu). If you don't want to do this, using PyInstaller might be not such a bad idea.
This should result in something as close to a self contained binary package as you can get and while I don't have much experience with PyInstaller myself, I think it does work rather well in practice. Jacob Barhak 6/7/2014, 12:29 น. Thanks Vadim, Your response is detailed enough for me to understand that I am mostly on my own here. I spent some time and money to upgrade to WxPython 3.0 a while ago. Robin helped me resolve some issues while upgrading on Windows. I had issues with GetRange warnings about deprecation then and those issues were fixed on windows.
And now I have a working installer with conda on windows. Now I want to add Linux support that was working at the past and it seems far from trivial. It was easier a few years ago. Yes, I remember times where I did not need to know what LibC was and did not need to compile anything. It seems the Linux issue has dropped between the chairs. Think about it - if someone now considers using WxPython for their project and reads these lines they understand that they need to do a lot of non python work for their system to work on Linux.
What if they are windows developers who just want things to work on Linux? Vadim, I assume you develop WxPython and therefore your vast knowledge. And I understand that you are really trying to help. Yet do realize that if you have the proper knowledge to properly build WxPython then creating a package on conda is not hard. I think Aaron did what you suggested with older libraries yet I am unsure of details since this is beyond me.
This is why I went to this list - to gain expert help. And I did try the conda list first. Rather than dismissing a possible solution, did you try to talk and figure out the best was to tie WxPython with conda? And please do not suggests untested paths of solution. If the packaging issue was so easy as portrayed here, then someone would have solved it by now.
Currently there is no solution for Linux. I hope I'll be able to return to this list with a resolution for my case at least. Yet it will take a while. Meanwhile thanks for the willingness to help and follow this thread. Jacob Sent from my iPhone Vadim Zeitlin 6/7/2014, 14:22 น.
On Sun, 6 Jul 2014 12:28:47 -0700 Jacob Barhak wrote: JB It seems the Linux issue has dropped between the chairs. This is definitely not the case for wxWidgets. I can't speak for wxPython for certain but I'm pretty sure you're somewhat exaggerating here as many other projects seem to be able to use it without problem. JB Vadim, I assume you develop WxPython and therefore your vast knowledge.
Actually this is not true, I don't develop wxPython at all. I work on wxWidgets, i.e.
The C API used by wxPython and am an occasional user of wxPython but I don't have any deep knowledge about it. JB And please do not suggests untested paths of solution. If the packaging JB issue was so easy as portrayed here, then someone would have solved it JB by now.
Currently there is no solution for Linux. I can be wrong but I'd really need some convincing arguments to prove it. From where I stand, I don't see 'conda' as the solution at all. I do know that building native Ubuntu packages does solve the problem so it seems natural for me to recommend that you just use them. I really can't add anything to what I already wrote. But you'll probably find more expertise on wxPython mailing list. At the very least there must be people distributing their software in binary form under Linux and you could ask them how do they do it.
I strongly suspect that the answer will be via Debian/Ubuntu packages, but, again, ask there to be sure. Jacob Barhak 6/7/2014, 14:34 น.
Thanks Vadim, If another mailing list is the solution I should really try there. This is actually very helpful. Jacob Sent from my iPhone On Jul 6, 2014, at 2:22 PM, Vadim Zeitlin wrote: On Sun, 6 Jul 2014 12:28:47 -0700 Jacob Barhak wrote: JB It seems the Linux issue has dropped between the chairs.
This is definitely not the case for wxWidgets. I can't speak for wxPython for certain but I'm pretty sure you're somewhat exaggerating here as many other projects seem to be able to use it without problem. JB Vadim, I assume you develop WxPython and therefore your vast knowledge.
Actually this is not true, I don't develop wxPython at all. I work on wxWidgets, i.e.
The C API used by wxPython and am an occasional user of wxPython but I don't have any deep knowledge about it. JB And please do not suggests untested paths of solution. If the packaging JB issue was so easy as portrayed here, then someone would have solved it JB by now. Currently there is no solution for Linux. I can be wrong but I'd really need some convincing arguments to prove it. From where I stand, I don't see 'conda' as the solution at all.
I do know that building native Ubuntu packages does solve the problem so it seems natural for me to recommend that you just use them. I really can't add anything to what I already wrote. But you'll probably find more expertise on wxPython mailing list. At the very least there must be people distributing their software in binary form under Linux and you could ask them how do they do it. I strongly suspect that the answer will be via Debian/Ubuntu packages, but, again, ask there to be sure. RegardsVZ - TT-Solutions: wxWidgets consultancy and technical support Igor Korot 6/7/2014, 14:40 น. Vadim/Jacob, On Sun, Jul 6, 2014 at 2:22 PM, Vadim Zeitlin wrote: On Sun, 6 Jul 2014 12:28:47 -0700 Jacob Barhak wrote: JB It seems the Linux issue has dropped between the chairs.
This is definitely not the case for wxWidgets. I can't speak for wxPython for certain but I'm pretty sure you're somewhat exaggerating here as many other projects seem to be able to use it without problem. JB Vadim, I assume you develop WxPython and therefore your vast knowledge.
Actually this is not true, I don't develop wxPython at all. I work on wxWidgets, i.e. The C API used by wxPython and am an occasional user of wxPython but I don't have any deep knowledge about it. JB And please do not suggests untested paths of solution. If the packaging JB issue was so easy as portrayed here, then someone would have solved it JB by now. Currently there is no solution for Linux.
Why do you say that it is untested? People do use it and I suggested you check it out and if it is satisfactory do the same. I can be wrong but I'd really need some convincing arguments to prove it. From where I stand, I don't see 'conda' as the solution at all.
I do know that building native Ubuntu packages does solve the problem so it seems natural for me to recommend that you just use them. I really can't add anything to what I already wrote. Problem here is that Ubuntu in their repository have an older version of wxPython, i.e. His solution uses 3.0 and he needs to package it. It seems he don't understand what me/you/Steve suggest - try PyInstaller/build Ubuntu package/ fix building issue.
Jacob Barhak 16/7/2014, 15:20 น. On Wed, Jul 16, 2014 at 4:30 PM, Aaron Meurer wrote: The issue with glibc is that each Linux has a version of glibc, and whatever version you build against, those packages are only usable with that version or newer. So if you build your package on Ubuntu 14, you will not be able to use it on Ubuntu 13, for instance. What we do is build against a very old Linux, namely CentOS 5, which has an old glibc, so that it is compatible with pretty much every version of Linux that is used today.
Aaron Meurer. On Sun, Jul 6, 2014 at 12:52 AM, Jacob Barhak wrote: Hi VadimAs promised, attached are results of running winpdb after installing WxPython through conda install. The first file shows the default installation that plain does not work and breaks on LibC. The second file shows the alternative installation by Aaron Meurer that does work, yet has some incompatibilities.
Aaron once told me he compiled against older libraries, yet since I do not know details you will need to ask him. And he also maintains conda, so you will be able to get information on conda at the same time. As for the build instructions being out out date, here is a link to the recipe I used to compile WxPython half a year ago: This is a bit different than the instructions here: The missing parts are the patch and the dependency installations before starting the build.
I had to collect those from multiple posts. Yet after building successfully something was still missing - the system worked with the python supplied with Linux, yet not with anaconda - GlibC again was the issue - as I mentioned it is a recurring nightmare. Yet since then Aaron supplied a working WxPython installation with conda. I just want it to work as in windows, Currently it raises the warnings as you see in the alternative file and does not behave like the windows version when running my system. GetRange also seems to be the warning that repeats itself and for some reason the alternative WxPython version cannot read text from a text box in once case that works well on windows. Now I have given you lots of information here.
Please understand. What I want are a set of instructions that will allow me to build a conda package on a fresh installation of Ubuntu 14.04LTS. Once this is done properly I can try to write a conda build script for those and upload the package to binstar so others can install it. The conda part should be easy if WxPython is properly prepared - as far as I understand. And since this works smoothly on windows and partially works on Linux already I think my solution is guided well. I appreciate the fast responses, yet I will not be able to build anything this week. So this give us all time to on solving this.
I will be able to communicate by email. Think about it, if conda will allow installing WxPython binaries well, then it will enhance WxPython attractiveness as a GUI solution.
Jacob On Sat, Jul 5, 2014 at 8:42 PM, Jacob Barhak wrote: Ok VadimFair enough. In a few hours you will get some errors generated by the current conda installation. I will also connect you to the conda maintainer to help figure out what is missing. Yet I can tell you that GlibC seems to be a recurring nightmare.
If this results in better WxPython binaries for Ubuntu it will be great. Jacob Sent from my iPhone On Jul 5, 2014, at 6:38 PM, Vadim Zeitlin wrote: On Sat, 5 Jul 2014 15:32:50 -0500 Jacob Barhak wrote: JB For example, the link you sent me contains out of date documentation. I looked it over before posting it and didn't see anything obviously wrong with it. What is the problem exactly?
And, if you already have the solution, perhaps you could fix it directly on the wiki? JB If you go through the build instructions it links to you will find out JB that they don't match the last version.
When I needed to build Wxpython JB 3.0 a few month ago I needed to use a patch that was not documented JB anywhere but this mailing list. I was eventually successful to some JB degree yet if I want my application to depend on WxPython I cannot JB leave this complexity to the user. It's difficult to tell anything about this without knowing what the problem was and what the patch is. JB Just to explain, my potential user may not know what python is. And JB some have trouble locating the command prompt.
IMO the solution to this problem is to build a normal Debian package which can be installed using the normal system tools (including GUI ones). JB The conda solution works on Windows. I don't know anything about conda, all I know is that there are dozens of similar systems. Some of them are more widespread than others (0install comes to mind), but I don't think any of them are ready to replace the packages in the system format (RPM or DEB) any time soon. So while I wish you good luck with solving your problem, I think this approach is misguided. RegardsVZ - TT-Solutions: wxWidgets consultancy and technical support.