Opening Projects via Short Name

[PaulMansour]

Kai has requested a way to open projects by a short name rather than having to enter the full path. This is stuff we had in past, when the location of projects on disk was controlled by Acre.

How would this work, be implemented, in Acre Desktop?

I suppose we would need a new acre command to associate a short name with a long path?

Should this just be left up to the user to configure his own session with short cuts and PFKeys, etc?

[norberturkiewicz]

We had a setup file in Acre 3 that did this. It looks like we're heading back to that if we want a lookup table. I'll probably use it but it has to be completely independent of the repository (project) folders.

[PhilLast]

Definitely. It would probably go in AppData. Acre3 had a complete editor. An association command ]whatever name /path would be easier.

[PaulMansour]

Does this affect anything more than ]openproject?

I am wary of it infecting all the commands, and then a whole new set of error messages when an association is not found.

I would prefer to leave this up to the individual user configuring his session. Kai?

[PhilLast]

OpenProject would recognise a symbolic name and look it up in a file in AppData. If there, all well and good. Nothing else would ever see it but we might have to do similar for servers when(?) we link this back to FlipDB.

[aplteam]

I would prefer to leave this up to the individual user configuring his session. Kai?

Actually that would be fine. Just the path will do.

[aplteam]

Second thoughts: when acre solves dependencies then it must manage the symbolic names itself because it's a recursive process, so it cannot be left to the programmer.

[PhilLast]

I still can't decide my own position on this. But I have a couple of observations that as yet I can't convince myself are misguided.

The symbic names in acre-3 are totally local. When the project is uploaded none of the config info goes with it. The Load and Open paramters rely on either a symbolic name or a path which is itself local. If I choose to have three different versions of the same project each has its own config and might load a different set of dependencies with a different set of symbolic names and a completely different hierachical relationship between their respective folders.

If in acre desktop we make the Load and Open params public, which we have done albeit that they do nothing as yet, then those relations, along with the symbolic names, if we allow such, and the actual folder tree structure in the machine of every participant must be identical because they are part of the project. If we clone (branch? fork?) a project then to the extent that we keep the config the same and that the paths are relative we will have to clone all the dependencies in the dependency tree, again with the identical folder heirarchy. But the paths must be relative because we can't rely on an identical drive/folder tree in every participant's machine.

[PaulMansour]

Kai, can you elaborate? What exactly does "solve dependencies" mean, and what do short names have to do with it?

[aplteam]

First of all, as Phil just pointed out to me, I should have said "resolve" rather than "solve".

We were discussing using symbolic names in the configuration file, but the longer we think about this the less sexy that looks. It just comes with so many complications.

We just agreed that it might be best to allow symbolic names to be used "locally", meaning that you can do

]acre.OpenProject Foo

but to disallow them in the config file.

That implies that any path specified for load or open in the config file should be a path relative to the current project.

I wonder whether we slowly realize why the packet management systems used under Linux all have central repositories. It means that the application name is our symbolic name, and the central repository has of course no trouble to figure out where is what.

[PaulMansour]

Well, with Acre 3 and 4, we have made Acre projects easy to put anywhere, which is good. But now we will find that with dependent projects, we will all be best served if we adhere to some conventions. It seems to me that they will flow from GitHub. All projects should go under a common "library" folder, the name is of this folder is up to each user. Each project should be in a company or personal sub folder. Only one level - the same as the GitHub address. So one GitHub we have:

/Dyalog/Conga /Dyalog/DFNS /CarlisleGroup/FlipDB /APLTeam/MarkAPL

And on our local machines we have

c:/.../AcreLibrary/Dyalog/Conga c:/.../AcreLibrary/Dyalog/DFNS c:/.../AcreLibary/CarlisleGroup/FlipDB c:/.../AcreLibrary/APLTeam/MarkAPL

[aplteam]

That's a limitation some users won't be able to accept. For security reasons people might have to separate acre managed projects, For example, APLTree projects are managed by DropBox, something that some customers might forbid.

Just an idea: rather having symbolic names for projects we could have symbolic names for paths:

Carlisle   = C:\CarlisleAcre4Projects
APLTree    = C:\APLwiki\APLTree
MyCustomer = D:\SecretProjects\

Then it's just

]acre.OpenProject [APLTree]\APLTreeUtils

or something similar.

[PaulMansour]

Its not a limitation, its just a convention so you can find things easier. Its just "if you want to find dependent projects, please place them relative to where the main or current project is."

I don't understand what symbolic names or paths have to do with the issue - or how they can help.

[PaulMansour]

I don't see how it matters if you keep your local projects on DropBox or not.

[e9gille]

I'm getting the feeling that there is a missing distinction between a project and its dependencies. I understand that Acre is able to manage multiple projects opened at the same time, this is powerful, but I don't know that you necessarily want to keep a central collection of projects that are accessed and worked on from potentially different parent projects.

If I have a project that depends on: Dyalog/Conga-3.0 APLTeam/MarkAPL-1.0 I would not expect to make changes to them, so loading them from a central library would be fine.

But if I am working on multiple, related projects I may want to open them all. In this case I would expect to clone the various projects (if using git) and place them in a separate (not a central/shared repository as above) location, possibly checkout specific branches of each and be able to work freely without affecting other projects.

This is where we need to discuss what a package manager is and what its role should be.

[e9gille]

As another example, I envisage being able to: ]apm.install Dyalog/DFNS which would get the project from "somewhere" (cloud/intranet/local machine) and install it in my current directory (apm = package manager). ]acre.loadproject DFNS would load the project as now.

If I wanted to make changes to an installed package I could, but it would be discouraged as a package should be treated as a versioned distribution.

To contribute to a project I would get the project (clone from git or other SCM) and then ]acre.openproject

I can see how in a corporate setting you may want to have a central, internal package repository for use in systems developed, but you need to have a separation of what is consumed and what is being developed.