Mechanism to have a local replica of required packs at project level

[fred-r]

This request may be a way to implement #93
It comes from a discussion we had in cpackget context: Open-CMSIS-Pack/cpackget#39

cpackget handles a CMSIS-PACK-ROOT repository of packs.
These packs are used by reference by the Open-CMSIS-Pack projects.

Now, I would like to have a mechanism to create a local image of the packs in use by my project, directly in the project tree.

Basically:

• we need to take the packs listed in the cprjs of the csolution
• we need to copy these packs in the project tree ("under project root")

Ideally, we must have a Pack Life Management :

• we may have a command to parse a standalone project and compare with the latest list of packs
  ** let the user know if a newer pack is available ?
  ** help him upgrade the project ?

• the end-user may have modified a component
  ** the end-user may want to contribute his changes
  ** he needs to "fork" the pack

• the end-user may want to update a pack version
  ** merge his changes ?
  ** override his changes ?
  Up to him to replace them if he made no changes => the tool can proceed automatically
  What about the RTE folder ? The end-user is allowed to make changes in the RTE folder
  Up to him to do the merge if he made changes in his local components => shall the tool help him here ?
  RTE folder must be in the scope of the diff

• the end-user may have a dependency A-->B-->C between components (--> means provides services to)

• the end-user may have modified component B
  ** what if component B is removed from new pack ? (keep former component ? let compilation fail ? warning ?)
  ** new version of B and C with the new version of C having new dependencies not satisfied by the modified local version of B (detect and merge ? let compilation fail? warning ?)

Basically, some of these scenarii can also happen when working by reference (except the component modification).
We may have a consistent behavior.

I do not think it is up to the Open-CMSIS-Pack vanilla tool to implement all the detailed behavior, but it must provide enablers:

• detect changes
• trigger merge
• ease forking

Bonus feature : as we will be working with "local packs", the source of a pack may be a .pack installed in the CMSIS_PACK_ROOT or maybe a github repository.

[jkrech]

@fred-r which tool(s) should provide enablers? Could/should this be an independent tool?

[fred-r]

Basically, as it is dealing with getting packs in a local folder, I would expect cpackget to provide this service.

Now, this means : is it cpackget parsing yml or cprj to get the list of packs ?
Or is it a 'frontend' offering this ?

In the spirit of keeping services with minimal dependencies and clear scope, I would say that cpackget can be in charge of managing the local copy but needs to be provided with the list and destination path ?
In this case, a "frontend" may be helpful to build the list of packs and determine the destination?

To me this is the role of the "IDE" to provide this glue.
OpenCMSIS may provide a front-end for this.
Maybe this is something ST may contribute ?

To be discussed with @slhultgren and @VGRSTM and @iomint

[jkrech]

Reading the above and thinking about it a little more, I actually don't think that cpackget is the right tool. As you rightly discovered above, this operation requires to read and write the csolution yml file. All the tool needs to know about the pack origin is $CMSIS_PACK_ROOT and <vendor>/<packname>/<version> and run a recursive copy since the expectation is that at this point the pack is already installed.

[ReinhardKeil]

pack: element supports a local path: to the pack. I believe this is therefore outdated.

[fred-r]

Disagree with the closure : the path attribute is not dealing with the copy, it is only a way to specify a known folder.

[ReinhardKeil]

@fred-r I guess what you are proposing is a process to copy all used packs locally and add a path to it. Using the cbuild.yml file it should be possible to identify the used packs.

Do you feel that a specialized tool for this should be developed? Or is it enough to just document a process.

[fred-r]

I see your point.
We can indeed keep this concern vendor specific and just leverage the path attribute.
I wonder if the path attribute could be flexible with an environment variable or something like this.

[ReinhardKeil]

Good idea, I created Open-CMSIS-Pack/devtools#820

@fred-r, given the set expectations, can we close this issue?