Skip to content

Implement support for a local registry #321

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
awvwgk opened this issue Dec 20, 2020 · 4 comments
Open

Implement support for a local registry #321

awvwgk opened this issue Dec 20, 2020 · 4 comments
Assignees
Labels
specification Issue regarding fpm manifest and model

Comments

@awvwgk
Copy link
Member

awvwgk commented Dec 20, 2020

Before we make fpm aware of the fpm-registry, we should create a minimal working implementation for a local registry (this registry might even be built-in to simplify things a bit at the beginning).

In analogy to Cargo we could use a syntax like:

[dependencies]
[dependencies.toml-f]
version = "^0.2.1"
registry = "internal"  # or URI to a registry
[dependencies.M_CLI2]
version = "^0.1.0"
registry = "default"  # for whatever the default URI will be

This requires:

  1. a way to specify and match version requirements (src/fpm/versioning.f90 defines only a version type)
  2. the possibility to cache dependencies in a project (we have build/cache.toml, alternatively a lock file)
  3. a format for the registry (JSON?, TOML?, XML?, SQL?) and an fpm package implementing the format
    (the fpm-registry has both TOML and JSON representations of the registry right now)
  4. an interface to fetch from URIs that are not local:// or file:// (libcurl interface or just shell escape to curl/wget)

A full registry is discussed in #35

@LKedward
Copy link
Member

This is a sensible approach. I think it would be beneficial to be able to specify a local path.

For parsimony it makes sense to use TOML for the registry format, to avoid needing an additional dependency.

For fpm-registry, I distinguish between the TOML registry file and the JSON index file; the former is manually edited and hence contains the minimum information necessary, whereas the latter is generated from the former and contains additional information required for browsing/searching packages. Some dependency information is also included which could be used to fetch dependencies faster. JSON was used merely because I thought I'd need to load it dynamically with Javascript, but then I realised that Jekyll could consume it directly. So the index format can change.

@awvwgk
Copy link
Member Author

awvwgk commented Dec 21, 2020

Should fpm be able to consume both a registry file and an index file (generating the latter by processing the former)?

@LKedward
Copy link
Member

LKedward commented Dec 21, 2020

I had envisaged that fpm would only interact with the index file since it can convey information stored within the package manifest without needing to download the package.

Generating the index requires downloading every package in the registry and reading its manifest, so I'm not sure we want fpm to do that?

@awvwgk awvwgk added the specification Issue regarding fpm manifest and model label Feb 3, 2021
@minhqdao
Copy link
Contributor

minhqdao commented Dec 21, 2022

To give the user the option to use an alternative registry, we thought about introducing a global configuration file that specifies the source of the registry.

It could be a config.toml file in .local/share/fpm that looks like this:

[registry]
path = "path"

or

[registry]
url = "url"

If no config.toml file or path or url keys were found, we'd draw the dependencies from the official one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
specification Issue regarding fpm manifest and model
Projects
Status: In Progress
Development

No branches or pull requests

3 participants