Prefixing manifest dependencies with organization name

[minhqdao]

To avoid name collisions and squatting, the current state (especially for the registry) would be that every dependency has to be part of a namespace (or organization or publisher). The question is now how that should look like within the fpm manifest.

Without namespace, get this dependency from the registry:

[dependencies]
name = "dependency_name"
version = "0.1.0"

With namespace:

[dependencies]
name = "organization%dependency_name"
version = "0.1.0"

This would, in theory, allow multiple packages with the same name to be incorporated:

[dependencies]
name = "organization%same_dependency_name"
version = "0.1.0"
name2 = "organization2%same_dependency_name"
version = "0.2.0"

I could envisage multiple kinds of separators for separating the namespace from the package name, like _, -, / or% (the latter is probably the most Fortran 😄). But distinguishing the namespace from package name in organization_name_package_name might be difficult using _ as the separator.

Of course, we could also add an additional required field as such:

[dependencies]
name = "dependency_name" (required)
organization = "organization" (required)
version = "0.1.0" (if not specified, get the newest version)

However, having to add another field might be overkill? 🤔

We also thought about adding namespaces for git dependencies in the same go.

How do feel about all of this?

[arteevraina]

I feel that specifying the organization name for every dependency that you use in the project using fpm is an overkill. Mostly, the package managers require you to type the dependency with their version number and that's it nothing more. This makes the developer worry less about the manifest configuration.

But, yes since we allow multiple packages of the same name under different organizations in the Fortran registry. I think the third option seems to be easier to read and less prone to commit errors.

[minhqdao]

I feel that specifying the organization name for every dependency that you use in the project using fpm is an overkill. Mostly, the package managers require you to type the dependency with their version number and that's it nothing more. This makes the developer worry less about the manifest configuration.

The thing is that specifying an organization name is supposed to be mandatory when uploading a package. If we'd need to resolve a dependency without an organization name specified, we'd need to query all orgs to find a package that has that name. And then throw an error if the package name was found more than once.

If a package has to be part of an organization, I think indicating the organization should be mandatory.

[perazz]

I also agree with @arteevraina. I would avoid polluting the name field with additional stuff. I think the manifest would be cleaner and parsing would be more standard with just one or more optional keywords like

[dependencies]
name = "dependency_name"
origin = "registry_name_or_address"
version = "0.1.0"

[minhqdao]

I think my initial suggestions were a bit confusing. Currently, there are three ways to include dependencies (they are the same internally):

[dependencies]
toml-f = { git = "https://github.com/toml-f/toml-f", branch = "main" }

[dependencies]
toml-f.git = "https://github.com/toml-f/toml-f"
toml-f.branch = "main"

[dependencies]
[dependencies.toml-f]
git = "https://github.com/toml-f/toml-f"
branch = "main"

I therefore think it makes most sense if we just add another namespace key. We will map its value to a new field in dependency_config_t so we will be able to differentiate path and git dependencies that have the same name, too. This might be interesting for @perazz.

Furthermore, we will add an optional v key (the version key is already used to indicate the package version). If not specified, the newest version will be automatically obtained from the registry. We can later use it for semantic versioning and version constraints, too.

[minhqdao]

Added namespace and v as additional keys.

[arteevraina]

@minhqdao Yeah looks pretty clean.