2013/1/31 Nick Hall <nick__hall@hotmail.com>
John,

Thanks again for your reply.

I was hoping that we wouldn't need to generate any file to hold constants. :)

However, I hate to say it, but we should probably be using Distribute (setuptools doesn't support python3).  If we want multiple versions then eggs are the solution, and I think that distutils doesn't support them.  Eggs can also contain resources!

Benny - would you like me to convert the setup script to use Distribute?

I did not investigate any of the options, so it is your, and John's, expertise we need to base decisions on.

I was hoping we could do a beta next, but changing how we install would mean another alpha. That is not a problem though, most important is that we are ready for a couple of years after 4.0 with the core things (install, core libs, ...), so if you think Distribute is the way to go, and the autumn 2012 releases of linux have what is needed to allow it, then I support that decision.

I do think we must allow gramps 4.0 to work on ubuntu 12.10 and current  suse/fedora, as otherwise not many people will be able to run it when released.

Benny


Nick.


On 31/01/13 19:26, John Ralls wrote:
On Jan 31, 2013, at 9:39 AM, Nick Hall <nick__hall@hotmail.com> wrote:

On 31/01/13 15:25, John Ralls wrote:
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.*
I don't think we should allow the average user to install more than one version of Gramps at the same time.  I also don't expect them to use distutils (although for linux it is quite simple).
Try to stop them. ;-)


Power users may well want to use distutils and install more than one version of Gramps (although I would strongly recommend running from source instead).


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.

I am happy to make rpm or deb files for testing, but generally don't do this.

Getting back to the original problem - we need to find the resource files at runtime.  I have just looked at the code again and noticed a few things:

1. We still substitute variables into const.py as we did with make. Do we still want to do this?
2. There is a bug with the distutils --install-scripts option.
3. We write the LOCALE_DIR twice.
4. The linux post install script still has bugs in it.

2 and 3 can easily be fixed.

If we decided to always determine the location of the resources at runtime, then the only remaining substituted variable would be VERSION.  Could we remove this into a generated file?
Const.py *is* a generated file. What's the benefit of making it not-generated and having another generated file instead?


Would we still need distutils to write out the installation locations anywhere?  What would we lose? (probably not a lot).  I'm happy to have only a single installed version.
We still need to allow developers to create distributions, build and install Gramps using distutils.

What are your views on this?

I'll start looking at the bugs. :)

Well, Gramps needs *some* way of discovering its resource files. It could at runtime:
* consult a private environment variable like $GRAMPS_DATA
* Search $XDG_DATA_DIRS
* Search "well-known" paths like /usr, /usr/local, /opt, /$HOME/Library/Application Support/Gramps (OSX), and whatever Windows uses
* consult GSettings (if that's not too much of a Gnome dependency)

Or we could keep the resources with the module and use relative paths.

The private environment variable and relative paths are simplest; searching XDG_DATA_DIRS probably needs well-known-path search as a fallback.

Remember my mistake as well: We need to be able to detect when we're running from a build tree and adjust the paths accordingly. We finesse that by creating different paths in distutils for "build" and "install". With a private environment variable we can just set it in Gramps.py, but the naming would have to be consistent.

Which brings up "icons/hicolor". That's used by Gnome theming [1], but I don't think that it works to have it in a private resource directory. It's supposed to be directly in one of $XDG_DATA_DIRS (e.g., /usr/share/icons/hicolor, not /usr/share/gramps/icons/hicolor). Since I rather doubt anyone is theming our icons anyway, let's just use "images" for installation. Driving the consistency theme, let's put the xml files in $PREFIX/share/gramps/data instead of $PREFIX/share/gramps, and the mo files in "build/locale" instead of "build/mo". DOC_DIR is used only to find LICENSE_FILE, which in turn is used only to provide the license file to the About dialog. Perhaps we could copy it into data as well and save having to worry about finding where we stuck doc/gramps.

Translation files are another interesting case. By convention, they're installed in $PREFIX/share/locale, but there's no actual requirement for that (and I think I'm on record being wrong about that). LOCALE_DIR is passed to gettext.translation() (or before my locale rewrite and therefore in Gramps4.0 gettext.bindtextdomain). We could as easily install to $PREFIX/share/gramps/locale as to $PREFIX/share/locale.

Next, we could version the resource directory, so that we have $PREFIX/share/gramps40, $PREFIX/share/gramps41, etc. Gramps would still have to find what $PREFIX is (see above) and figure out when it's supposed to be running locally, and I think $GRAMPS_DATA is the easiest way to do that.

Regards,
John Ralls

[1] http://developer.gnome.org/icon-theme-spec/