OpenProject doesn't load dependencies listed in acreconfig.txt

[e9gille]

I might be doing something wrong here, but I have created ProjectA and ProjectB and put htem as siblings in a folder: E:\projects\ProjectA E:\projects\ProjectB

In ProjectB I configure it to load ProjectA:

:Namespace
    CaseCode←'On'
    Load←'../ProjectA'
    Open←''
    ProjectSpace←'#.ProjectB'
    StartUp←''
:EndNamespace

I start Dyalog and then: ]acre.openproject E:\projects\ProjectB

It loads ProjectB, but not ProjectA. What am I missing?

Also, in the Wiki it says I can provide a pair of folder and space names for Open or Load. In the case I want to load ProjectA as space PA, what is the correct form (do you need to nest it appropriately I mean)?

{
      "ProjectName": "MyProject"
      "ProjectSpace": "#.MyProject"
      "Open": ["ProjectA", "PA"] or  "Open": [["ProjectA", "PA"]]
      "Load": ""
      "StartUp": ""
}

[PaulMansour]

Sorry, we should probably make this clear somewhere, I don't think Phil actually has implemented this yet. The Wiki has run ahead of the implementation. As we are getting this off the ground, I have the taken the liberty of writing what should be, not what its. I think it should all be in sync withing a couple of weeks if not sooner.

[PaulMansour]

I have added a wiki page to note not yet implemented features. This might appear a bit silly, but I don't really want to maintain separate design and documentation wikis at this point.

[aplteam]

I don't have a gear icon when I look into an issue!

[e9gille]

Thanks Paul. Can I suggest you put a:

⚠️ {feature} not yet implemented

or

🚧 {feature} under construction

## :warning: some text ## :construction: some text

directly in the wiki page of the missing features

[PaulMansour]

Done. (not the features, but the warning symbols in the wiki.)

[PhilLast]

Fixed

[PaulMansour]

Awesome, thanks.

[PhilLast]

Was thinking of putting out a release but realised this isn't quite complete. At present assumes an absolute path or relative to whatever the "current directory" is. We discussed relative folder-paths and what they should mean when specified in a config file (say): "C:/one/two/acreconfig.txt"

:namespace
      open←'three' '/four' './five' '../six' '../../seven'
      ...
:endnamespace

but I'm not sure it was conclusive. [each of these can be the first of a nested pair also to specify the project-space but I've got that sussed and am not dealing with that here] If I catenate each of the above onto the present folder path they resolve to 'C:/one/two/three' 'C:/one/two/four' 'C:/one/two/five' 'C:/one/six' 'C:/seven' The first three of which are of no use being within the present folder. Should I process them to be more flexible - perhaps by prefixing '../' to each - and publish the protocol or just assume people know what they're doing. _(not sure I do.) And what are the conditions under which I don't even catenate the present folder? At the moment I'm not doing it if there's a colon ':' in there.

[PhilLast]

Also in answer to Gil's second question at the top of this thread the nesting for pairs is as follows ignoring issues covered in prev post:

'alpha' → (⊂'alpha' '')
'alpha' 'bravo' → ('alpha' '')('bravo' '')
'alpha'('bravo' 'charlie') → ('alpha' '')('bravo' 'charlie')
(⊂'alpha' 'bravo') ←→ (⊂'alpha' 'bravo')

So the rule is A simple string or depth two list represents folders only - depth three specifies pairs. To specify a single pair enclose it. Dyalog 16 has left-shoe underbar "⊆" representing "enclose if simple". Then I'm doing the equivalent of: 2↑¨⊆¨⊆open

[e9gille]

Thanks Phil On the question of paths, I think I would expect the following for your examples: 'C:/one/two/three' 'C:/four' 'C:/one/two/five' 'C:/one/six' 'C:/seven' I don't like the idea of automatically prefixing it with ../.

If the idea is that you would typically load sibling projects I refer to my other post in issue 15. I would argue that if you have dependencies you should find them nested in your project folder or maybe even from a central location on a separate drive.

If you are concerned the user gets the path wrong, this could be somewhat helped if dependencies were installed with a package manager that updates the config file as part of the job of adding a package to the project.

[norberturkiewicz]

I agree with @e9gille on the (hidden) automatic prefix of ../ to paths. I think it should be explicit and clear that the reference will start from a folder that's one up in the tree.

[PaulMansour]

I don't think of there as being a hidden ../ and I don't think of anything being prefixed.

Think of it this way: a project is like a file. Its a unit. (it's implemented as folder because we have to - like an excel file is secretly a folder) If you tell a project about another project using a short, unqualified name, you would assume this other project to be found at the same location as your main project, you would expect them to be siblings. You certainly would not assume it to be inside the project.

When you are inside the dyalog interpreter and you access a dll with a short, unqualified name, where do you expect to find that dll? You expect to find it where the dialog.exe is. Similarly, if you are in a project, and you reference another project with a short, unqualified name, it should be found in a similar way. The fact that you may be seven levels deep in subfolders within the project should be irrelevant.

I think of it as being relative to the project folder, not relative to the acreconfig.txt file, the location of which is somewhat of an implementation detail.

If the path is relative to the location of the .txt file, will anyone ever start a path with anything other than ../? Maybe an absolute path c:\, but that is probably bad form.

If you had a GUI for acre, and edited the config file using a GUI, you may not even realize where the config file is, and be confused that you need to prefix your dependent path with ../.

[PaulMansour]

When I say above "the path is relative to the project folder" I realize that may be a source of confusion. I think I should say "an unqualified project name is assumed to be at the same location as the main project" ... I'm sure that can still be better stated....

[PaulMansour]

Gil, I think the issue of the what the path is relative to is somewhat independent of whether a "dependent" project is something that is a static given, or something that you work on concurrently. Both need to be supported. The issue of nesting dependent projects in your main project is something I have been thinking about. If you are not going to clone a repository, if you are just taking a "release", what form does it take? I don't think it is going to be a folder with thousands of files, it is going to be a workspace, no?

Also if Project A depends on B, and B depends on C, then is C nested in B, which in turn is nested in A?

[aplteam]

I think dependency might be nested but it should not be the default, and is probably not the recommended way of doing it.

When A relies not only on C (which relies on, say, Z) but also on D which also relies on Z then nesting all of them would mean to have two copies of Z buried in the tree.

[PaulMansour]

Kai, true.

There is also the issue of where the project goes in the namespace tree in the workspace.

I assume the point of nesting, or one of the points, is to lock in a version. If Project A relies on B and C, and B relies upon D version 1 while C relies on D version 2, you are going to need two version of D.

Not only will you need to versions of D in the file tree, but two versions in the namespace tree. The project must be relocatable to do this.

Note that if a project has no file resources, that is , all it takes is a namespace of APL code, much of the issues of nesting goes away.

[e9gille]

I don't think you need to nest projects deeply. In your example, when working on Project A, all dependencies could be loaded flat into a single container in A's project folder: /A/dependencies/B /A/dependencies/C /A/dependencies/D/v1 /A/dependencies/D/v2

When working on Project B: /B/dependencies/D/v1

When working on Project C: /C/dependencies/D/v2

For all projects, the dependencies could be loaded into matching namespaces:

.B

.C

.D.v1

.D.v2

[PaulMansour]

I think a lot of what I write above is nonsense. Lets try again:

With respect to the paths of dependent projects, the starting point is the directory that the main project is in. Thus if this is the project FlipDB:

c:/Projects/CarlisleGroup/FlipDB

Then the starting point is c:/Projects/CarlisleGroup and if FlipDB asks for Rumba , it is expected to be here:

c:/Projects/CarlisleGroup/Rumba

While if it asks for ../APLTeam/MarkAPL it is expected to be here:

c:/Projects/APLTeam/Rumba

Alternatively, maybe the definition of the Open and Load parameter value is NOT a path, but the global identifier for a package/project? Of the form Company/Project. It maps to a local folder by convention in that if Company is omitted, its at the same level, if Company is provided, it is up and over one. If not found, it goes out to the internet and gets it - or something like that, In this case, it is simply required that for loading dependent projects, they are organized in sibling folders by company,

[PaulMansour]

Fixed.