[texworks] Automatic update of resources

[Jérome Laurens]

Le 20 janv. 2011 à 07:55, Stefan Löffler a écrit :

> Hi,
> 
> On 2011-01-18 16:47, Jérome Laurens wrote:
>> your solution does not apply to machines shared by different users (all machines for students at the university).
>> When upgrading, only one user sees the scripts and templates updated:
>> the one who did the upgrade.
> 
> Really? Did you try this, and what did you do exactly?

My mistake, there is a problem, but it is in fact related to the local configuration:
the sys admin has configured all the laptops to automatically downgrade the user profile to a trusted state.
Unexpected.

> 
> Since there are no shared resources at the moment, every user either has
> his/her own resources, which should get updated whenever the respective
> user runs a new version of Tw, or central shared resources (via the
> portable mode), which would then have to be updated by the sysadmin.

This is suitable for resources which only depend on a static context.
Unfortunately, no resource is absolutely static, even images.
They may change (and should change) from time to time.
Of course things like latex resources are more static than TW scripts,
this is why TW always should have both a private resources repository, a shared resources one and a personal one.
I agree that this is not straightforward, the first step is to define a proper API to ask for resources and settings,
which implementation just redirects to the actual one.
The next question is how would it cost to convert the actual code to conform to the advanced API ?
No simple answer, but is can be done progressively with no harm.
Then once everything is converted, the implementation of the advanced API can change.

> [...]
> Regarding the above-mentioned issues:
> As long as the user can only add new definitions/settings, everything
> should be fairly straight forward. The problems emerge when the user
> should also be able to modify and/or remove/disable settings in the
> system-wide resources. For example, suppose the system-wide resources
> define a setting A, which the user wants to unset. Writing "A=" could
> not be distinguished from actually setting A to an empty value (which
> may not be the same as unsetting A in some circumstances). This would
> require a diff-like file format, which is not particularly
> user-friendly, however. Or how would you disable/override a system-wide
> template, which is a file of its own? An empty file is something
> completely different from no file at all.

About settings, it is not a good idea to use things like "A=" because they render the code difficult to read.
Prefer things like "A=0", "A=NO", "A=''", "A=Undefined".
In your example, you have 2 different tests
1) whether A is set or not
2) when A is set, what is the value
In that case, the code must conform to the logic: a boolean for 1) and a value for 2)
Merging the logic by using 2 settings instead of 1 will render things difficult to debug.

Concerning the file problem: how can we disable/override/overwrite a system-wide file.
- The easiest: to overwrite a system wide file
- Less easy: override a file
this is relevant for things like settings files. For them you can open all the setting files in a definite order and return the first occurrence of the setting in that list.
- worst case: to disable a file, you must define a dedicated setting "List of ignored files". The default value of this list is void.

> 
>> It may allow to install the app on a movable drive.
> 
> And in portable mode, the situation gets worse. Does the user want to
> relocate only his personal directory (~Library/...)? Or run Tw fully
> portable (i.e., override /Library as well)? What if the sys-admins wants
> to relocate the global directory (e.g. to /Tw)? Or the sys-admins wants
> to relocate the user's directory (say, to a network share, or even a
> virtual/dynamic directory)?

If the user runs Tw from a usb drive, we can assume that there is no Tw available on its machine.
Everything should be "run" from/to the usb drive, ignoring whatever is on the machine.
Tw should focus on "standard" situations.
At first glance, Tw can test whether it is run from the system volume or not. If not, it can ask the user if it should run in portable mode, and what portable mode exactly.