Open config parameter

[PaulMansour]

Should the Open config paramter be called "Dependencies"? To turn it off, we use -dependencies=off, so that is some sort of argument.

I have been using my own property named Dependencies to define dependencies, but everywhere it is equal to Open anyway. I'm going to get rid of it and use Open, but it seems a case can be made to rename Open as Dependencies.

[PaulMansour]

We may want Acre to do a little more with respect to dependencies when a project is opened, like setting up cross-project references, and Open seems to be a result of what Acre does to a dependent project. That is, if a project has dependencies, we open them. We don't say if a project is open, it is a dependency.

[PaulMansour]

Obviously dependency info is critical forsome sort of package manager thing. But it has to be stored and maintained somewhere, and it seems the proper place is the acre config file.

[aplteam]

Well, when the packacke manager finally materializes then every package needs its own description file with plenty of meta data, dependencies on other packages among them,

On Thu, 15 Aug 2019 at 18:41, Paul Mansour notifications@github.com wrote:

Obviously dependency info is critical forsome sort of package manager thing. But it has to be stored and maintained somewhere, and it seems the proper place is the acre config file.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/the-carlisle-group/Acre-Desktop/issues/190?email_source=notifications&email_token=AD5XJHJK5VVEMK6VE4YX4KTQEWILLA5CNFSM4IMAIZWKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4MPSWY#issuecomment-521730395, or mute the thread https://github.com/notifications/unsubscribe-auth/AD5XJHKLAKZNLWBMMAHPB73QEWILLANCNFSM4IMAIZWA .

[PaulMansour]

Well, when the packacke manager finally materializes

Right after world peace.

Seriously though, the package configuration file would have to sit right next to the acre config file, no? It could also get some of its stuff from the acre config file. We don't want the same thing in two places regardless. So if it is not in the acre config, it goes in the package config.

[PaulMansour]

Perhaps if we rename Open config parameter to Dependencies, then the Dependencies option should be renamed to OpenDependencies.

[PhilLast]

Not sure what you mean by the last comment but I've thought for a log time that "Open" doesn't cut the mustard. "Dependencies" would be good.

If we change it we might have to live with both for a while or acre could (I could) break the phobia of a lifetime and programmatically amend an existing config file if acre found "Open".

[e9gille]

A package manager would not have the concept of a project, its domain is the managing of creating packages, publishing them to a registry and installing them locally from a registry. A package could have dependencies on other packages, so this would need to be listed in its meta data somewhere

A project could have dependencies that are only required during the development process. Distinguishing these devDeps from Deps is in Acre's domain. In the step of creating a package from a project, a subset of the Acre config file could form a basis for the package's meta-data, dependencies would be one of these things.

[PhilLast]

Reading through the entire topic again I now grasp Paul's last comment but both Open← and -dependencies= are aimed at precisely the same data so probably should continue to be homonyms.

I see why Gil wants to differentiate. Acre is primarily a development tool and the dependencies are provided during a development session by default even if the developer's intention/expectaton exceeds that. I might be mistaken but I believe the option to be able to turn them off was added at the time the discussion about package management was taking off in these pages.

I'd be happy with a name that reflects the development status of the data.

[e9gille]

This all relates to the different states of development of a module. You work on a project that depends on external modules. If those other modules are maintained by a 3rd party, you would typically not want to modify them. In this case, packaging up these modules and distributing them via a registry makes it easy for a developer to consume them.

In Paul's case some or all of the modules are maintained by himself and he wants an easy way to work on them all at the same time without jumping through hoops. Acre currently supports this by assuming that the other modules (defined in the Open parameter) are Acre projects. It does not however link the modules together, which forces the project code to use full path references to the external modules. This doesn't lend itself very well for versioned and controlled releases of the various modules.

The list of dependencies for a project must exclude references to local Acre projects if the project is published to a registry. In addition, a package should list its compatibility with dependencies by specifying a version for each dependency.

The Acre-config could mix the ability to open other (local) acre projects with packages that are fetched from a registry, as long as there was a clear syntax to differentiate this. If so, when it comes to publish a package to a registry, it would have to signal an error if the list contains references to local Acre projects.

What I'm trying to say is that the concept of Open and Dependencies is confusing because you are mixing up packages and projects.

• All dependencies should be linked to the main project (ref created in the project space) by Acre, weather or not they are packages or Acre projects. The term Dependencies is therefore more appropriate in a project config file.
• The term Open in a config file is more appropriate in a workspace config file where you are working on projects in isolation.

Example

I work on Rumba that depends on Conga. I can open the Rumba project in isolation and Conga will be loaded from the registry. After some work I find I need to make a change to Conga as well. I can open the Conga project as well, make the changes, publish a new version and then update the Rumba project to fetch the latest version, finally being able to test the change and make sure it works (awkward). If I find I do this often, or I like this workflow, I could create a workspace config file that opens the 2 projects at the same time.

Alternatively, I can change the dependency on Conga from the registry to the local Acre project. Reloading the Rumba project, Acre will now open both projects while maintaining the ref to Conga from Rumba. Now I can change both projects and test them at the same time. When happy with the result I try publishing a new version of Rumba. An error is signaled as the list of dependencies contains a local Acre project. Aha, I forgot to release the Conga changes. After publishing the new version of Conga, I revert the dependency to the latest published Conga from the registry. I can now publish a new version of Rumba.

The example above involves only 2 projects. In theory both of those could have additional dependencies. For example, Rumba may depend on a PackageX that also depends on Conga. Note that PackageX would (arguably) use its own copy of Conga from the registry in the above scenario, even when Conga is loaded from an Acre project. That would be decided by the version strategy implemented.

[PaulMansour]

Thanks all for comments.

To the specific question at hand, Gil and Phil I think seem to be in agreement that Dependencies is a better name than Open. I vote that going forward we assume that Open will eventually be renamed as Dependencies and treat them as the same thing. They can both exist for as long as necessary. Phil can add Dependencies whenever convenient. If both params exist, Open would be ingored.

I think Phil wants to keep the switch as -Dependencies=on|off to mean lead or do load the dependencies. This is fine by me.

This is obviously a very minor change, and only one of terminology.

If we all OK with this, let's do it.

[PaulMansour]

Regarding the additional comments by Gil (thanks for the detailed comments Gil - I am still struggling with this stuff and its very helpful):

It [acre] does not however link the modules together, which forces the project code to use full path references to the external modules.

I am going to propose soon that Acre does in fact link the modules together, avoiding both absolute and relative paths. I'm experimenting with some techniques now. Obvioulsy, in the end, whatever technique Acre uses must be the exact same technique that the package manager uses, preferably running the exact same code to set it all up.

An error is signaled as the list of dependencies contains a local Acre project.

Is there any way this can be handled automatically? If I clone a project that has 5 dependencies, and I open the project, the 5 dependent packages get downloaded and opened. If however I cloned 2 of the 5 dependent projects, then it would be nice if I didn't have to monkey with any config files to work on them or to publish new versions of the primary package.

[e9gille]

Is there any way this can be handled automatically?

Well yes, it could be semiautomatic, but the point is that the developer has to make a conscious decision to either keep the dependencies on the same version or bump them.

If you clone 2 of 5 projects then the acre config should specify that. If you then want to publish a new version of the primary project and the package must not specify dependencies on cloned projects, then you would either need to make a decision as to what version of those 2 cloned projects it is compatible with.

It seems sensible to me that you would ask the developer to actively make a decision and not assume that the version number specified in the acre-config is OK to go with. Basically working with cloned projects increases the risk that you publish packages with incompatible dependencies specified.

[e9gille]

Btw, in Julia you can issue a command to flip between a package and a cloned repository. Say you have installed Conga as a package and want to make changes to it, you could say APM.Open Conga and it would find the repository URI from the package meta data, clone the repository to a configurable location and reload the source.