On Jan 31, 2013, at 5:51 AM, Nick Hall <nick__hall@hotmail.com> wrote:

On 31/01/13 02:03, John Ralls wrote:
No, distutils isn't capable of building dependencies AFAIU, especially not C dependencies like Gtk. On Macs, which are at least Unix, there are several tools available for building chains of dependencies, including jhbuild, MacPorts, Homebrew, and Fink. Windows has Mingw/MSys, but their package manager still has a lot of rough edges. None of them are suitable for even "power users". Consider all of the trouble Helge has gone through the last couple of weeks trying to get Gramps4 running on Windows. At least he found a pre-compiled Gtk stack. 

If you want to reach the average Mac and Windows user, you have to provide a one-stop download it all and install it package. Mac users, especially since the App Store spread to OSX from the iPhone, expect to be able to drag the application package into their Applications folder and to start using it -- Except for the ones who want to drag it somewhere else. And want to be able to change their minds where they put it. And have more than one version not interfering with each other.

Thanks, this explains the issues quite nicely.  So it seems that we don't need to spend any time customising distutils for Mac or Windows.


The normal way to deal with that is to just keep everything in the bundle and determine the path to the resources at runtime. There's actually a nice API for finding resources in an app bundle, but it's available to Python only via PyObjC, an enormous module that wraps the entire OSX API. I don't think we want to go *there*. 

packaging (distutils2) is supposed to have much better support for resources, but it wasn't usable when I last investigated.


It's of course possible to check some "well known place" and if that's not populated or has the wrong version install the files there. That opens the possibility of version conflicts, though... of course, so does the current distutils scheme, as Benny pointed out earlier.

This is why I hard-coded the paths for the resources at installation time.  The current code should work with multiple installations without conflicts.  Of course, it would be possible to deliberately create problems, but only users that know what they are doing would normally install multiple copies of Gramps.

If you think that there is a problem with running multiple versions please raise a bug.  I didn't test this very thoroughly.  :)

I'll do some more test installations today, and see if I can also find you problem with the image locations.

I don't mean that there's a problem for a developer who runs distutils to install Gramps. That's what, 10 or 15 people? The thousands of people who use Gramps to manage their genealogy projects use their distro's package manager or the AIO installers for Mac and Windows. *They can't write Python code, and they don't want to learn. Most of them don't even know how to use a command line. They're not using distutils.*

If you're going to do reasonable tests, you need to make whatever package your distro uses (rpm, deb, etc.) and, putting yourself in the shoes of your distro's packager, set it up so that Aunt Martha can have 3.2,  3.4 and 4.1 on her machine, because she wants to give 4.1 a try before she commits to switching, just like she did with 3.4 (which is why 3.2 is still there, she never got around to removing it). She thinks she knows what she's doing.

Regards,
John Ralls