Does anyone use the $LOAD_PATH/Scripts folder?

[Renerabbitt]

What are you using it for? what can you do with this?

[Joe_Carrick]

I don't use it.

It could be useful if you wanted to write a macro (on the fly) and save it into the scripts folder - or something similar in the data folder.

But really it's just used by Chief internally to know where to get things.

[Renerabbitt]

1 hour ago, Joe_Carrick said:

I don't use it.

It could be useful if you wanted to write a macro (on the fly) and save it into the scripts folder - or something similar in the data folder.

But really it's just used by Chief internally to know where to get things.

can you tell me more? I have no clue as to what it even is

[BenMerritt]

The LOAD_PATH variable is used with Ruby's "require" function, which loads an external script file into the current Ruby process. Those script files can contain basically any valid Ruby code, which makes for a convenient place to put helper classes and so forth.

[Joe_Carrick]

To elaborate on Ben's statement:

• ".rb" files can be stored there and "required".  I think the Ruby "Tutorial" is one such file.

[SHCanada2]

There was a gentleman last year who had to manage many macros and users, and decided instead of putting them in the template files, and perhaps copying them between templates, to instead put them in their own .rb file in this directory. That way if he had to make an update, people would not need to update every plan that they were working on to get the newer macro results. he would just copy the new rb file to their directory

 

Downside is, if one opened an older file which at the time, had a different result from that macro which maybe has been changed three times since that older file was last opened, you would be unable to obtain the original result without having to go into the directory and revert to the macro file of the day that older file was printed.

 

So one has to assess, how often that downside would occur. or perhaps manage it another way, like creating a new macro if an update to a macro would have a material difference to older files, or worse would break because there is a new parameter that was not available at the time

 

Or I suppose if you were really really diligent you would incorporate some sort of versioning on the execution of that macro