[Lazarus] Lazarus config woes

[Hans-Peter Diettrich]

Martin schrieb:

>> When multiple directories are in a search path, the search stops on 
>> the first item (file...) found. That's common practice, isn't it?
> 
> I explained below, but I do again.
> 
> In order for that to work, WITHOUT the user needing to be aware of doing 
> anything. EVERY lazarus must come by default with local config.

No. When the global config is in the search path as well, as should be, 
and is without -pcp, then the global config is found.

It smells like you search for an excuse for the weird decision, that 
(currently) the *global* config path is overwritten by -pcp. The global 
location can be used (be in the searchpath) implicitly, as the last 
resort, no need to ever specify it explicitly.

> Then local config will ALWAYS be found, which is the same as having NO 
> GLOBAL
> 
> If Lazarus comes without a local conf by default, then we are back to 
> where we are now => a global copy will be created, and used

A global config is be created only when none exists. Otherwise that 
global config is used *and* updated, by default. The unaware user may 
wonder afterwards, why his other Lazarus install will fail or behave 
unpredictable, due to the changes in the global config :-(

Specifiying an (non yet existing) -pcp creates a config in that place, 
but its unclear from where the settings are read.



> *** There is one option though, since we have the setup dialog => it 
> could ask the user where (e.g. exe dir) to create the config.
> 
> BUT that is at best a partial solution.
> Because, if a user installs a 2nd lazarus, it may not (yet) have a 
> problem with the global config. However the use may then change it, and 
> the glabal config gets updated. The global conf now is incompatible with 
> the 1st/original installation. That is almost never what the user wants. 
> the user wanted a new config for the 2nd installation. (but now the 1st 
> install will ask about creating a new one).
> 
> Since the 2nd installation (if the config is compatible at the time of 
> first startup) has no way of knowing there is another install, it just 
> requires the user to tell it.

Exactly what I mentioned above.

As long as the Lazarus directory is stored in the config, the IDE can 
compare it with the current/given directory. When both differ, a new 
config can be created automatically, in the actual Lazarus dir. At least 
the user should be informed of such an obvious mismatch, and be asked 
for specification/confirmation of the directory to use (create/overwrite).

In the simple case, when the next IDE invocation with the same arguments 
finds the same Lazarus directory mismatch, it also will find the 
previously created config in the Lazarus directory, and can use it 
automatically - no need for any further updates.

But when its required to specify the new config explicitly as -pcp, then 
a new script or desktop shortcut will have to be created, or an existing 
one has to be updated accordingly. This should be told and left to the 
user, because IMO any automatic updates may fail for various reasons.


>>> But if  the search order for config would be:
>>> - exe-dir
>>> - global as current
>>>
>>> Then as soon as a global config exist you are back to were you are now.
>>
>> Something seems to be wrong with your list. Mine looks like this:
>> 1) explicit -pcp
>> 2) EXE dir (meaning the Lazarus dir from which the EXE was built)
>> 3) global dir
>>
> the explicit pcp dir makes no difference to anything that I said below

It does, even if you may not have noticed yet (see above).



>>> => But if the user is unaware of the issue, he will not ad that 
>>> config to lazfoo, and run with the global config => same as now
>>
>> When no global (default) config exists, the new config (eventually) 
>> can be stored there, else the obvious place is the Lazarus(~EXE) 
>> directory.
> 
> Well that leaves the question why almost every software has moved from 
> exe config to global config?

For several reasons:

1) Apps usually are stored in directories, which are not writeable by 
the user.
This is okay to prevent the user from garbling his system, but is 
inapplicable when the user is allowed, and may be forced, to rebuild the 
IDE. That's why a Lazarus EXE *never* should be stored in a place, that 
is not writeable by the user.

2) In multi-user environments, typically managed by an administrator, 
all users shall share common binaries, while every user shall be free to 
use his own preferred settings.

3) After [2] it turned out that most apps will deserve machine specific 
(protected) settings, in addition to user-editable settings. That's why 
most configs are organized in a hierarchical manner, not only in a 
simple global/local fashion.
This is the situation where I vote for a separation of the Lazarus 
config, into an installation specific part (mostly the pathes to 
external tools), and into user preferences, which are applicable to 
multiple installations (versions) of an application.

4) Apart from all that, it still makes sense to have all-in-one 
distribution kits, for e.g. evaluation purposes, that can be installed 
and removed without affecting the machine permanently, and do not 
require administrator privileges for that purpose. Recent examples are 
plug-in distributions, on chip cards or USB sticks.


> Config in the user dir has many advantages. Various backup solutions 
> will take care of it, user profiles that can be used accross many 
> workstations.....

When backup solutions have to take explicit care of such things, this is 
*not* an advantage.

Current Lazarus configs are *not* shareable, neither across multiple 
local installs, nor across workstations. This argument deserves a 
redesign of the config storage, with a separation into 
installation-specific and -independent settings.




>> I have no problems with startup scripts, as long as I do not have to 
>> write them myself, must remember where I placed and how I named them, 
>> etc. ;-)
> 
> Well that's a new topic. If a profile manager was created, it could have 
> the functionality of creating desktop shortcuts (including fro linux)
> 
> Though personally, on linux I never use the desktop, I always use a 
> shell. And I have my own startup scripts for most apps that I use

Vive la différence :-)

I've often been thinking about writing my own installation manager, but 
finally I was happy whenever I could make a new installation work, 
without going into implementation details.

What nerved me specifically was the inability to have multiple user 
accounts for isolated Lazarus installations. If this had been working on 
Windows, I had been happy with dedicated users for e.g. standard release 
versions, and other(s) for current development (SVN/Git based).


>> But I have a BIG problem with non-shareable configs. When I have to 
>> configure manually every new Lazarus installation, because it is too 
>> stupid to configure itself, or it overwrites the configs required for 
>> my other installations, then something is wrong :-(
> 
> But the config is currently shared? That was the whole point of this 
> discussion.

I think that you pointed out yourself, above, that effectively no two 
Lazarus installations can share the same config.

But perhaps I overlooked something, so a last question: where can I find 
the documentation of the Lazarus commandline options, mentioned allover 
this thread?


> With local/exe-dir configs, that problem remains/becomes bigger.
> 
> Otherwhise this is a change of topic: Keeping the config directory as it 
> is, but make sure the data in the config will not conflict between 
> installations

Right, we can close this thread, after all arguments have been exchanged.

DoDi