fusesoc icon indicating copy to clipboard operation
fusesoc copied to clipboard

Allow provider section external to core file

Open olofk opened this issue 5 years ago • 4 comments

Add support for getting the provider from an external file (e.g. fusesoc.provider in the library root). This would allow using the same .core file for local and remote cores

olofk avatar May 08 '19 12:05 olofk

@olofk Is there already some ongoing development on this topic? And if so, I might think about supporting it as it would simplify my workflow a lot.

andmeyee avatar Dec 17 '20 14:12 andmeyee

Chiming in with my additional enthusiasm for this feature. ;)

martin-lueker avatar Feb 12 '21 18:02 martin-lueker

So though I'm sure @olofk has a number of ideas on this, I suppose one implementation could be as simple as:

  1. Adding a flag to a "provider corefile", say "provider-only"
  2. Download all "provider-only" cores while still calculating dependencies
  3. Whenever we fetch something from a remote repo, do another scan for corefiles in the fetched copy.
    • This is important for subcores that may be in the remote repo, but not explicitly listed in any libraries. This is an issue that prevents some local cores from becoming remote ones.
  4. Ignore the provider-only corefiles when actually building the final dependency tree.
    • If after a provider-only corefile doesn't actually dig up the required core, well then you are out of luck. Time for FuseSOC to finally give up and die, (but not without having put up a good fight!)

Is that similar to what you had in mind @olofk?

martin-lueker avatar Feb 12 '21 18:02 martin-lueker

It was so long ago I last thought about this so my memory is a bit hazy, but as I recall it, the idea was to put a library.conf in the root of a library (could be more elaborate and be a number of files, but let's simplify for now)

This file (or files) would contain a list of mappings between a VLNV, a location to the .core file and a provider section. Hopefully we can require that the path to the core file is simply an URL but I'm not sure if this would allow for git repositories without e.g. a web frontend. Oh well, perhaps focus on the simple case to begin with.

It could look like this

"olof_kindgren_enterprises:award_winning_cores:serv:1.0.2": #VLNV
  core : https://raw.githubusercontent.com/olofk/serv/1.0.2/serv.core #URL pointing to core file
  provider: #Provider section as would normally appear inside the core file
    name    : github
    user    : olofk
    repo    : serv
    version : 1.0.2

When the dependency manager requests the vlnv, FuseSoC will download the core file, parse it and add the provider section. Voilà! We have a regular remote core now. (The core file could be cached for performance reasons, but it's not strictly required. For sake of simplicity we could also download all core files specified in the library.conf file. I reckon there aren't too many of them and it would probably make life easier on the dependency resolution side if we have everything locally. (Other problems exist with this approach, but still)). Whaddaya think?

There are more dynamic approaches to handle the situation, but this would take care of the big issue of core file replication which I think willl become a bigger problem once more users post their cores online

olofk avatar Feb 28 '21 21:02 olofk