project.AcreConfig

[PhilLast]

A while back the suppression of this reference was discussed but no decision was made.

My own take on it was that I had always hesitated to inject anything into the project space. Currently acre creates projectSpace.AcreConfig and projectSpace.quadVars if the name is not already in use.

Since shortly after our discussion, acre has exposed the functionality to create it on demand by calling a function to return a clone of the internally saved ref in the following iterations:

'config' ⎕SE.acre.run projectSpace    ⍝ deceased
⎕SE.acreAPI.config projectSpace       ⍝ deceased
⎕SE.acre.Config projectSpace          ⍝ active
]acre.Config projectSpace             ⍝ active

To be of use after the project had been closed the function or command would have to have been run and its result captured before the project was closed.

No decision need be made immediately as all that is required is to remove an executed assignment in CreateProject. @norberturkiewicz @e9gille @aplteam @PaulMansour

[e9gille]

I may have been the one to argue for its injection, but to be honest the main reason was to be able to find the path to the project folder. This is particularly important for dependencies to easily find their own assets.

Since then I found that when building an application from a project, I want the path to be relative to the application (.exe or .dws) to make the application relocatable. So I ended up replacing the AcreConfig.ProjectFolder in all dependencies with a relative path.

[PaulMansour]

Like Gil, I must read the config file and set the project folder myself anyway, to make the project relocateable, and in addition I stuff a bunch of other stuff in there both permanently on disk and more things at runtime. (Now acre reads all the params, so that is not an issue for the permanent stuff) I'm not sure everyone else distributes the config file as I do with the project/package/application, but it is a critical part of the app. If you don't, you are going to have put all the info in the config file somewhere else anyway. I write to this file under program control to update the version, which is stored there.

So basically, when I open a project in dev mode, the first thing I do is read in and reset acreconfig in the project space. Since I opened the project, I obviously know the ProjectFolder, so no problem. In any runtime distribution, I know something, like the []WSID, and a list of included projects that must be relative to the []wSID, so I can read the config files and set the config namespace into each projects, with a fully qualified ProjectFolder , so each project knows where it is.

[PaulMansour]

So, to sum up, Acre could stop injecting it, and I don't think I would notice.

[e9gille]

Well, I didn't mean that it was OK to remove it. My point is that the framework will need to provide a way for a package to find its home folder. Weather that is a single constant char in the root of the project space or as a member of a config space, it should be provided by the framework.

The fact that the build step is replacing it with a relocatable path was just to highlight that we both found that it (the ProjectFolder) had to be changed, but the code still requires it to be there.

[PhilLast]

My intention was to garner your opinions as to whether we could dispense with the injection of AcreConfig into the project space because there is a function that allows you to retrieve it on demand when and if you need it so long as the project is "open".

[norberturkiewicz]

I use .AcreConfig in pretty much every project at startup or build. Removing it from acre will just move the code to my Init function. I guess it would allow us to set it another folder... I.E settings<-[]se.acreApi.loadSettings’’.

I’m indifferent so whatever makes the acre code cleaner.

[e9gille]

And I failed to make my point because I keep thinking of this from a package framework point of view that potentially doesn't require Acre.

If I as a developer know that the framework will always provide me with the project's home path in a specific name in the project space, I can code without reference to the acre API at all the code will work both under Acre and beyond.

Just like the SALT framework injects SALT_Data, I would like there to be at least a HOME_PATH injected. If the project requires more info, it could chose to read in the rest of the config file given the home path. Of course, it would be easier to read said config file if it was in a format that could be read without acre being available.

[PhilLast]

I think the consensus is that I leave it as it is.