Re: [Gramps-devel] Relocatable Data Dirs

[Nick H. <nic...@ho...>]

John,

I've just looked at your code.

Very neat!  It does everything I was looking for.

You can commit it as far as I am concerned.

Nick.


On 10/03/13 23:11, Nick Hall wrote:
> On 10/03/13 20:29, John Ralls wrote:
>> On Mar 10, 2013, at 7:40 AM, Nick Hall <nic...@ho...> wrote:
>>
>>> On 10/03/13 03:32, John Ralls wrote:
>>>> OK, it makes no real difference to the program, and having setup.py install just write the prefix path into a file is certainly
>>>> easy. I suggest that we do in fact store the prefix as passed in on the command line to setup.py install and write it to
>>>> gramps/gen/prefix (no extension). I'll add a singleton DataPath class in gramps/gen/utils/datapath.py which looks for
>>>> $GRAMPS_DATA, reads the file, and sets class variables locale_dir, data_dir, image_dir, and doc_dir in __init__, which
>>>> const.py can export... pretty much the same way it does GRAMPS_LOCALE. Gramps.py can set $GRAMPS_DATA to its
>>>> own directory, and the non-existence of prefix will tell datapath to use the build layout instead of the install layout.
>>>>
>>>> Sound good?
>>> John,
>>>
>>> This sounds OK to me, but I think that I need to remind you of some of the background to this.
>>>
>>> 1. When I first suggested writing the "prefix" to a separate file the idea was rejected.  The decision was that distutils should write directly to const.py rather than creating an extra file.  Now we are proposing an extra file and also an extra DataPath class.
>> Whose decision?
> I can't find the thread right now, and I don't think that its
> important.  I made the suggestion so we could make const.py static,
> which I'm sure you've gathered I'm in favour of.  :)  The comments in
> the thread were something along the lines of: "why not just write to
> const.py rather than create a new file?".  I lost interest at that point.
>
>
>>> 2. I went away from using the term "prefix" because it has a different meaning in distutils. In fact, it is possible to install the modules, resources and scripts to completely different directories.  (I can't see why anyone would want to though)
>> Yes, that's possible with autotools, too. I've never seen anyone take advantage of it, but the Since we're speaking only of resources here, how about that ('resources' or maybe 'resource-path'  or even 'installed-resource-path')  instead of prefix?
> 'resources' would be good, but I'm not too fussed.
>
>
>>> 3. From my point of view, I got into this by offering to help Rob out.  I don't have any experience in writing installers, so I think it would be best to get Benny or Brian to comment.
>>>
>>> Just a few more comments:  :)
>>>
>>> It would be nice to make const.py static.  This solution would enable that.
>>>
>>> Would it be better to have const.py the single place to define path constants, rather than creating a DataPath class?
>> const.py will be the single place to *get* the path constants. DataPath (or, for consistency, ResourcePath) is what makes them constant.
>>
>> I'll expand on that:
>> File IO is expensive, and the resource path file isn't going to change, so it should be read only once. Checking the path to make sure that it's valid is more (expensive) file IO. The reason to push that job into a separate class is that that allows us to do the operation only once. In C we'd just declare a static variable. That's not an option in Python, the equivalent is a singleton class.
>>
>> I've coded it up and force-pushed it to Github for you to look at.
> OK.  I'm with you now.  I'll try to look at the code tonight.
>
>
>> Note that I had to separate VERSION from const.py in order to make this work. It's now in gramps/version.py
> I have no problem with that.
>
>
>>> We seem to be moving towards using DATA_DIR, DOC_DIR, and IMAGE_DIR indirectly.  Do we want to restrict their use outside of const.py?
>> I don't see that. DOC_DIR is used only in const.py to set LICENSE_DOC for the about box (so it can be removed), but DATA_DIR and IMAGE_DIR are used directly in several places.
> Take IMAGE_DIR, for example,  when doing the file re-organisation I saw
> SPLASH and LOGO used from const.py and also constructed from IMAGE_DIR.
> There was no consistency.  I assumed that SPLASH and LOGO were newer
> code.  Maybe I was wrong.  It is not relevant to this discussion really
> anyway.
>
>
>>> Do we still need the GRAMPS_DATA environment variable?  If so, should we rename it to GRAMPS_PREFIX (or GRAMPS_SHARE)?
>> Yes, to allow the path to be relocatable. That's the whole point of this, remember? I have no particular attachment to the name, so if we call the file some variation of 'resources', perhaps GRAMPS_RESOURCES would be a better name for the environment variable.
> I seem to be missing something here.  I thought it was about running
> multiple installed versions of Gramps (which I never saw the point
> of).   We were trying to avoid search for the resources a runtime, so we
> wanted to get the packager or installation program to write the resource
> location somewhere at install-time.
>
> Having a environment variable would be one solution.  I was suggesting
> that a file be an alternative.
>
> Once Gramps is installed we know where the resources are.  I don't think
> we need the user to be able to change the location via an environment
> variable.  Or is this for developers?
>
> Regards,
>
> Nick.
>
>>> We should try to keep the solution neat and simple.
>> Neat, yes. If by 'simple' you mean 'elegant', no problem. ;-)
>>
>> Regards,
>> John Ralls
>>
>>
>>
>
> ------------------------------------------------------------------------------
> Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
> Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the
> endpoint security space. For insight on selecting the right partner to
> tackle endpoint security challenges, access the full report.
> http://p.sf.net/sfu/symantec-dev2dev
> _______________________________________________
> Gramps-devel mailing list
> Gra...@li...
> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>
>