Capture dependency resolver

[dgarijo]

In systems like python, or Java, we don't capture the dependency resolver.

For example, is conda the resolver, or does it go against pypi?

Is it maven central or is it jitpack?

We should think about this for the next release.

[juanjemdIos]

Currently, dependency_type is already being used beyond the Conda environment parser. It is also present in the parsers for bower, composer, gemspec, publiccode, cabal and all toml-based formats (cargo, pyproject, etc.).

At the moment, its primary purpose is to distinguish the role of the dependency (dev - runtime).

[dgarijo]

The dependency type is a different thing. For each dependency, we may have to distinguish:

• name (e.g., pytest)
• version (e.g. 1.0.0)
• dependency_type (e.g., dev, run)
• resolver (e.g., conda, pypi, jitpack, maven central)

[juanjemdIos]

So... I think I understand the problem. The dependency_type field was already correct in all parsers except the conda environment parser, where we were using the resolver (“conda”, “pip”) instead of a correct dependency type. Environment.yml does not distinguish dev vs runtime dependencies, so everything in that file should simply be treated as runtime.

About the new dependency_resolver field, most parsers will have a single resolver determined by the file being parsed (ej:, composer.json: composer, bower.json: bower, package.json: npm, pom: maven or jitpack...). Only a few formats can contain multiple resolvers in the same file, such as environment.yml (conda + pip) or our toml parser that have several diferent files.

Of course, I'll update the documentation to include the new dependency_resolver field. This time I'll remember :)