WxPython Build and install - is there a simple way?

[Jacob Barhak]

Hello,

 

Does anyone have an easy way to install WxPython that is more or less the same on all platforms?

 

WxPython is needed for the application I develop - MIST:

https://github.com/Jacob-Barhak/MIST

 

It is a dependency that the user needs to install. I am trying to make it as easy as possible for the user.

 

Currently only the Python(x,y) distribution includes PxPython and the scientific libraries I need - yet it is only available on PC - and MIST also needs to run on Ubuntu - for HPC through SGE. And although you can find binaries for WxPython is it cumbersome for the user. I am trying to get to a point where there is a simple installation that is more or less similar on all platforms.

 

The Anaconda distribution has the ability to define new packages through binstar.org - this should allow me to package my code and install dependencies in a similar fashion. Has anyone tried to create a recipe for WxPython installation through a conda command in anaconda?

 

I did try pip install and easy_install and those did not work. If there was a working pip install, it would have been possible to automatically extract the recipe for conda. However, since these do not work it seems I will have to build WxPython from source. I did try this also, none of the instructions on the WxPython Web page seem to be up to date. I looked at:

http://www.wxpython.org/builddoc.php

http://www.wxpython.org/BUILD-2.8.html

 

The 2.8 instructions do not match whatever is in the tarball and I failed building those in the past - just got lost with dependencies.

The 2.9 instructions are simpler yet when I run the build script it fails to find opengl.

 

I was using anaconda python on Ubuntu 12.4.

 

The only solution I know of installing wxpython on anaconda Ubuntu is to use the package manager and install the binaries and then copy them from the python package directory to the Anaconda distribution package directory. And I needed expert support to find this solution.

 

If anyone is willing to help me create binstar packages for WxPython, or at least help guide me through the make process so I can build a recipe myself I will be grateful - and it will help other users get a simpler installation - one that is platform independent.

 

I hope someone can help.

 

             Jacob

 

http://sites.google.com/site/jacobbarhak/

[Vadim Zeitlin]

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
http://www.tt-solutions.com/

[Jacob Barhak]

Hi Vadim, and Hi to anyone else who can help,

Ubuntu 14.04 LTS is out. The synaptic package manager does not show wxpython 3.0 - it has 2.8. Did I not see it, or perhaps it is not there yet?

In any case, my issue is larger. I am trying to get wxpython to work on Ubuntu for quite a while now. I tried multiple solution, including trying to build from source:

https://groups.google.com/forum/#!msg/wx-users/VRY7NLM2Aac/HrH-SNFu_NEJ

However, I am still stuck with the inability to install wxpython seamlessly for a user different than me on Ubuntu. It seems just too complex - even for a developer.

An interesting solution came from the Continuum Analytics People and their conda package manager. They actually were able to create a set of binaries that installed easily using the conda command. You just type:

conda install wxpython

And it installs wxpython 3.0 on windows and on Linux.

The Windows installation works well. However, the Linux installation fails on Ubuntu 12.04 and 14.04.

The conda tool also allows people to create their own packages on channels on binstar.org and share those. Aaron Meurer created a version of wxpython on his channel that installs on Ubuntu 12.04 with the command:

conda install wxpython -c asmeurer

However, this version, does not seem to behave the same as the windows version and raises too many warning messages. However, it is good enough to support important tools such as winpdb. Here is a link to a conda group discussion about this:

https://groups.google.com/a/continuum.io/forum/#!topic/conda/MeQyHQiMxp8

Note that virtually anyone can create a package in binstar.org and people can then reuse that package when they install their python applications. Actually, it is easy to define wxpython as a dependency and make its installation almost invisible to the user for an app that uses wxpython . Therefore it seems natural for a wxpthon installation to be available via conda.

My question is if anyone has any idea on how to create a conda /binstar installation that will work on a bare bone Ubuntu 14.04 without need to apt-get anything. If anyone has such a solution, please let me know and I will gladly test and if working use as a dependency for my app.

The installation problem has been open for years and now there are tools that can help close this for good.

I hope someone can help with this.

            Jacob

[Vadim Zeitlin]

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 (http://packages.ubuntu.com/trusty/libwxgtk3.0-0)
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
http://wiki.wxpython.org/How%20to%20install%20wxPython 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.

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]

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 GLib_C 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]

Hi, Jacob.

On Sat, Jul 5, 2014 at 1:32 PM, Jacob Barhak <jacob....@gmail.com> wrote:
> 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.

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.

Thank you.

> --
> Please read http://www.wxwidgets.org/support/mlhowto.htm before posting.
>
> To unsubscribe, send email to wx-users+u...@googlegroups.com
> or visit http://groups.google.com/group/wx-users

[Jacob Barhak]

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 easy_install 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]

Jacob,

On Sat, Jul 5, 2014 at 2:36 PM, Jacob Barhak <jacob....@gmail.com> wrote:
> 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.

Check out py2exe and pyinstaller.
I don't have a reference for the former but pyinstaller can be found
at www.pyinstaller.org.

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.

Thank you.

[Jacob Barhak]

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]

Jacob,

On Sat, Jul 5, 2014 at 3:20 PM, Jacob Barhak <jacob....@gmail.com> wrote:
> 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.

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.

Try it.

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.

Thank you.

[Vadim Zeitlin]

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]

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]

Ok Vadim,

Fair 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 Glib_C seems to be a recurring nightmare.

If this results in better WxPython binaries for Ubuntu it will be great.

Jacob

Sent from my iPhone

[Igor Korot]

Jacob,

On Sat, Jul 5, 2014 at 6:34 PM, Jacob Barhak <jacob....@gmail.com> wrote:
> Thanks Igor,
>

> Your enthusiasm is in place yet does not provide a solution.

Thank you.
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 my_script.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.

Nope. I don't. 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]

Hi Vadim,

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 Lib_C. 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:

https://groups.google.com/forum/#!msg/wx-users/VRY7NLM2Aac/HrH-SNFu_NEJ

This is a bit different than the instructions here: http://www.wxpython.org/builddoc.php

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 - Glib_C 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

[Jacob Barhak]

Hi Igor,

You are digressing from the main topic of installing WxPython on Linux. Perhaps we should continue this discussion in another thread to avoid confusing Vadim who is trying to help in a path that is closer to my solution path. I understand that you are trying to optimize my system in your way, yet it may not be the best fit for me at my situation.

I will try to answer you in here in hope this will satisfy your curiosity and close this path. My system is called MIST - MIcro Simulation Tool. Here is a link to it: https://github.com/Jacob-Barhak/MIST

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.

I do not care about size of installation. My system runs in HPC environment and entire anaconda with all packages you can think of installed will be tiny compared to the data processed by the system. Yet I heard the name mini-conda from Peter Wang in one of the Austin python meetings, perhaps this is the solution to the size issue you were mentioning.

I do care about the environment being the same and Anaconda gives me that solution and also gives me an AMI when I need to run things on the cloud.

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.

Therefore instead of reinventing my system to solve the installation problem I am trying to just resolve the last difficulty I have - WxPython installation on Linux. Since I already have working solution with conda I want to use this tool. It is easy enough to do. It just requires figuring out some details by a few experts.

I hope this text explains my reasoning and will help navigate the discussion in the direction of finding a solution for installing WxPython.

Thanks again for trying to help.

                  Jacob

[Steve Barnes]

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 <ikor...@gmail.com> 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:

1. Not be littering your users disk space with generated file,
2. Not be vulnerable to malicious persons tampering with the content of such files, (one classic approach is to add code to such files),
3. In some cases this may avoid false alarms of possible malicious code,
   
4. Run faster on most systems as you are working entirely in RAM.
5. 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:
1. may cause conflicts with code that they are also using, e.g. by upgrading libraries to incompatible ones,
   
2. may require permissions that they do not have, (to install python and libraries you typically need root access),
3. may be a space problem on some systems
   

The only slight problem is that your generated python scripts may use libraries that are not used anywhere else in your code - in this case since pyinstaller tries to make as small a binary as possible it may leave those packages out of your build, this is simple enough to resolve - simply force ipyinstaller to include those libraries by either specifying in its build file that they must be available or simpler to me have an if false:import or two.

The same approach can be used with py2exe, (on windows only), and I have done so successfully.

Sorry if it seems that I a sticking my oar in - as a kubuntu user I agree it would be lovely to simply pip install wxPython, or even apt-get, - but I do understand that there are a lot of variants to support and a very fast release cycle which may well complicate the process.

Gadget/Steve

[Igor Korot]

Jacob/Steve,

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.

Thank you.

>
> Gadget/Steve

[Jacob Barhak]

Thanks Steve, Thanks Igor,

Your points are taken. Yet please agree with me that my bottleneck is build WxPython on Linux to work properly.

If this is solved I can later install with multiple systems. I can have a conda install and another type of install.

Let us then please focus on making WxPython easily install on Unubtu. Hopefully many other solutions will spring out.

Jacob



Sent from my iPhone

[Igor Korot]

Hi, Jacob,

On Sun, Jul 6, 2014 at 2:46 AM, Jacob Barhak <jacob....@gmail.com> wrote:
> Thanks Steve, Thanks Igor,
>
> Your 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.
That is it.

No pain of installing 3rd party libraries, no wxPython installation,
no python installation.
Nothing. Zero work for user. Download and run.

It will not require tweaking of anything (AFAIU, you had to fix
something for conda).
1. Install PyInstaller.
2. Package you script.
3 Distribute binaries.
4. Move to another OS.
5. Goto step 1.
6. 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.

Thank you.

[Jacob Barhak]

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]

Jacob,

On Jul 6, 2014 3:36 AM, "Jacob Barhak" <jacob....@gmail.com> wrote:
>
> Thanks Igor,
>
> Yet 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.
Sorry.

>
> 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?

Thank you.

[Vadim Zeitlin]

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 Lib_C.

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> https://groups.google.com/forum/#!msg/wx-users/VRY7NLM2Aac/HrH-SNFu_NEJ
JB>
JB> This is a bit different than the instructions here:
JB> http://www.wxpython.org/builddoc.php
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 - Glib_C
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]

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 Lib_C 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]

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]

Thanks Vadim,

If another mailing list is the solution I should really try there.

This is actually very helpful.

Jacob

Sent from my iPhone

[Igor Korot]

Vadim/Jacob,

On Sun, Jul 6, 2014 at 2:22 PM, Vadim Zeitlin <va...@wxwidgets.org> 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. 2.8.
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.

Thank you.

[Jacob Barhak]

Thanks Aaron,

First, again, I note that your solution for installing WxPython is the best I tried so far - yet it is not perfect - when running, some things do not behave the same as before or as WxPYthon on windows. I assume this is the price of using older libraries.

Also note the discussion on this thread where I try to compile WxPython on the same system and run it on the same system:

https://groups.google.com/forum/#!topic/wx-users/75mT1NpbbBo

The version issue you are describing is similar to someone running away with a code version while different system go in different directions all having their own version that is incompatible and therefore the instability.

However, some stability should be established at least on one Linux system. If I build on a certain system, I expect the code to work there for me and for others. Currently I am unable to do even this - see the link above for transcripts.

I do not mind declaring that my system will work and be supported only on Ubuntu 14.04LTS. And I will be ok with a different Linux distribution where I can install Anaconda and Sun Grid Engine. Yet currently I found no Linux system where WxPython 3.0 works.

I assume WxPython maintainers made this work on at least one Linux platform. If I can install anaconda and SGE on the same Linux platform, I will be happy and declare it as being supported and make my conda install work there and adding a note that the installation was tested only on that platform.  

Note that since Ubuntu 14.05 LTS should be supported for a few years, if there will be a solution there, it would work for a few years, this is why I chose it as a candidate.

I hope someone can point me in a proper direction.

                  Jacob

On Wed, Jul 16, 2014 at 4:30 PM, Aaron Meurer <aaron....@continuum.io> 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