How are packages organised in workspace

[e9gille]

I suggested previously that packages could be loaded into the workspace and organised following a convention:

.[author].[package-name].[version]

This avoids loading in the same code multiple times if a package is used by multiple other packages.

The main project code could then use a reference to the dependency to make it easier to consume. The question is:

• should the developer assume this convention and therefore use the full path to access dependencies? Don't like this in case the convention were to change for whatever reason.
• will the framework provide an api for this? Something like M←require'MarkAPL' returning the reference to MarkAPL that this project has listed as a dependency.
• will the framework inject references? So in your project #.MyApp your functions access MarkAPL directly without having to do anything.

[PaulMansour]

Good questions.

Certainly the developer should not use the full path to refer to a versioned dependency, or any I guess. At a minimum, one would cover it in a single place.

I like the idea of injecting references. I'm not sure that this should be done automatically or universally, as it opens the door to name conflicts. Injecting references has the advantage of being able to click on a function and see the source while developing. You can't do this if you have function that returns a reference to the project at runtime.

I'm starting with a little function to call manually in a startup routine:

SetReference source target name

For example:

      SetReference #.CarlisleGroup.Utilitites #.CarlisleGroup.FlipDB 'U'

...will establish U as pointer to #.CarlisleGroup.Utilities in every namespace under FlipDB.